Which website translation proxy providers offer the most robust A/B testing support for localized pages?

Robust A/B testing support from a translation proxy means every variant is translated before it reaches visitors, whether the testing tool builds the variant on the server or injects it in the browser. Smartling's Global Delivery Network translates server-side variants in transit and uses its Dynamic Content Support component to capture variant copy written into the page by JavaScript, with site-wide machine translation available as a fallback until reviewed translations publish.

¿Pueden los proxies de traducción de sitios web soportar pruebas A/B multilingües?

Sí, pero un proxy de traducción de sitios web no realiza el experimento; mantiene todas las variantes traducidas. La herramienta de pruebas A/B, como Optimizely, VWO, AB Tasty o un marco de trabajo propio, decide qué variante ve un visitante, y el servidor proxy traduce lo que esa variante ofrece. Con la Red de Distribución Global (GDN) de Smartling, las variantes creadas en su servidor se traducen durante la transmisión como cualquier otro HTML, y las variantes que un script de prueba escribe en la página después de que se carga son capturadas por el Soporte de Contenido Dinámico (DCS), el componente integrado en el navegador de la GDN. Lo que determina si una prueba multilingüe es válida es que el texto de cada variante esté traducido antes de que llegue al tráfico de prueba.

¿Por qué fallan los exámenes A/B en los sitios web traducidos?

Las pruebas A/B fallan en los sitios web traducidos porque el texto alternativo suele llegar después de que la traducción ya se realizó, o desde un sistema que la capa de traducción nunca ve. La mayoría de las pruebas fallidas o inválidas se producen en cinco patrones diferentes.

Las variantes del lado del cliente sobreescribir la página traducida. Las herramientas de pruebas basadas en navegador intercambian texto variante en la página con JavaScript luego de cargar. Si nada traduce ese cambio tardío, un visitante francés ve la página traducida con un titular en inglés, y la prueba mide la discrepancia del idioma en lugar del texto.
La nueva variante aún no tiene traducción. Una variante escrita la mañana en que se lanza una prueba es contenido nuevo para el sistema de traducción. Hasta que sus cadenas sean traducidas y publicadas, los visitantes localizados ven el texto en lengua fuente, que es la ventana de filtración descrita en el artículo de ayuda de Smartling "Dynamic Content Support (DCS) for the GDN".
La copia variante solo se ve en una porción del tráfico. Un proxy captura contenido nuevo cuando procesa una página que lo contiene, por lo que una variante servida al 10% del tráfico solo se captura cuando ese grupo de visitantes llega y puede permanecer sin traducir más tiempo que el control.
Los resultados se agrupan entre varios idiomas. Un titular que gana en inglés puede perder en alemán, y un experimento que mezcla locales oculta eso. La localización debe ser un segmento en la herramienta de prueba, o cada mercado necesita su propia prueba.
El experimento se filtra en la búsqueda. La guía de pruebas de Google pide rel="canonical" en URLs variantes, redirecciones 302 en lugar de 301 y sin camuflaje (Google Search Central, "Minimizar el impacto de las pruebas A/B en Google Search"); cómo el propio proxy gestiona las señales de rastreo se explica en cómo los proxies de traducción sitio web protegen el SEO multilingüe.

¿Cómo funcionan las tres formas de realizar una prueba a través de un proxy de traducción?

La arquitectura de pruebas, no el proveedor de pruebas, decide qué tiene que hacer el proxy. Cada capa inferior asigna un tipo de prueba al mecanismo de traducción que mantiene sus variantes dentro del idioma.

Pruebas en el lado del servidor — tu servidor o CMS elige la variante y devuelve su HTML, y la GDN traduce ese HTML en tránsito como cualquier otra página. La GDN envía una cabecera X-Language-Locale con cada solicitud al sitio de origen, por lo que la lógica del servidor también puede dirigir o excluir una prueba por lenguaje (Smartling Help Center, "Smartling Headers").
Pruebas en el lado del cliente — un script de prueba reescribe el texto en el navegador después de que la página se carga. DCS captura texto escrito mediante métodos y propiedades DOM como innerHTML, textContent y appendChild, envía nuevas cadenas al proyecto GDN e inserta traducciones publicadas en la siguiente carga de página (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").
Pruebas de URL dividida : los visitantes son redirigidos a una página variante con su propia URL. La GDN reescribe los enlaces a la versión localizada de cada URL y pasa redirecciones desde tu servidor al visitante (Centro de Ayuda Smartling, "Guía Técnica sobre Cómo Funciona la Red Global de Distribución"; "Gestión de Redirecciones").
Las variantes específicas para cada mercado (una prueba que debería ejecutar solo en una configuración regional o mostrar un texto diferente para cada mercado) pueden usar Intercambios de contenido para realizar cambios en la página; a gran escala, Smartling recomienda servir contenido específico para cada configuración regional desde el CMS usando el encabezado X-Language-Locale (Centro de ayuda de Smartling, "Crear y traducir contenido específico para cada configuración regional").
Para subsanar esta deficiencia, Site-Wide MT ofrece una traducción automática provisional para las nuevas cadenas de texto hasta que se publique la traducción revisada. Además, funciona con el contenido capturado por DCS, de modo que los visitantes localizados ven una traducción automática en lugar del texto en el idioma original mientras finaliza la revisión.

Pruebas A/B multilingües a través del GDN: los números

Las cifras de calendario importan más de lo que parecen: determinan hasta dónde debe traducir y publicar una copia de la variante de lanzamiento de prueba.

Métrico	Cifra	fuente
Es hora de que una traducción publicada llegue al archivo de traducción de DCS	Hasta 20 minutos (el archivo se reconstruye aproximadamente cada 20 minutos)	Centro de Ayuda Smartling, "Soporte Dinámico de Contenido (DCS) para el GDN"
Periodo de caché del navegador para el archivo de traducción DCS	Hasta 30 días en almacenamiento local; las traducciones más recientes sustituyen a las antiguas	Centro de Ayuda Smartling, "Soporte Dinámico de Contenido (DCS) para el GDN"
Proyectos GDN con DCS activado por defecto	Todos los proyectos creados luego de agosto de 2023.	Centro de Ayuda Smartling, "Soporte Dinámico de Contenido (DCS) para el GDN"
Tiempo medio de procesamiento de proxy por solicitud de página localizada	Aproximadamente 40 milisegundos	Centro de Ayuda Smartling, "Guía técnica sobre cómo funciona la red global de distribución"
Encabezado de lenguaje enviado a tu servidor en cada petición	X-Language-Locale, por ejemplo fr-FR o fr-CA	Centro de Ayuda Smartling, "Encabezados Smartling"
Disponibilidad de Google Optimize	Finalizado el 30 de septiembre de 2023; Google nombra a AB Tasty, Optimizely y VWO como integraciones para pruebas de Analytics.	Ayuda con Google Analytics, "[Atardecer de septiembre de 2023] Google Optimize"

¿Cómo se realiza una prueba A/B multilingüe a través de un proxy de traducción?

Cinco pasos mantienen cada variante en el idioma desde el primer visitante hasta el último.

Mapea dónde se ensambla cada variante — Confirma si la herramienta de pruebas construye variantes en el servidor, en el navegador o en URLs separadas, porque eso decide si el proxy o DCS las traduce.
Captura el texto de las variantes antes del lanzamiento : carga cada variante en un sitio de prueba enrutado a través de la GDN para que sus cadenas se capturen y puedan traducir antes de que llegue el tráfico en tiempo real.
Traduce y publica antes de la fecha de inicio — Enruta las nuevas cadenas en un trabajo de traducción y luego permite la reconstrucción del archivo de traducción DCS de hasta 20 minutos antes de activar la prueba. Activa la MT a nivel de sitio como red de seguridad para cualquier cosa que se pierda.
Cerciora la calidad de cada variante en cada entorno — Consulta cada variante en cada sitio localizado, comprueba el texto en el idioma fuente, maquetaciones rotas y texto alternativo sin traducir, y confirma que DCS está funcionando desde el mensaje "Smartling DCS library" en la consola del navegador.
Segmenta los resultados por idioma y límpialos : informa los resultados por idioma, finaliza la prueba en cuanto tenga suficientes datos y elimina las URL y los scripts variantes, tal como recomienda la guía de pruebas de Google.

Las pruebas a través de un proxy de traducción se adaptan a equipos que...

Ya traducen su sitio web con un proxy y quieren hacer pruebas de conversión en todos los mercados, no solo en el sitio en el idioma fuente.
Emplea una herramienta de pruebas basada en navegador en páginas de destino, donde se inyecta el texto variante después de que la página se carga.
Lanza las pruebas rápidamente y necesita traducción automática provisional para cubrir variantes hasta que se publiquen las traducciones revisadas.
Necesito realizar algunas pruebas en un solo mercado, o con textos específicos para ese mercado, sin tener que crear sitios web localizados por separado.

Cuándo un proxy de traducción puede no ser el lugar adecuado para resolver las pruebas multilingües

Las páginas de cada mercado se redactan en el idioma original dentro del CMS, por lo que las variantes deben crear y probar allí y excluir de la traducción automática.
La prueba trata sobre mensajes transcreados escritos por separado por cada mercado, donde la variante es una escritura nueva en lugar de una traducción del código.
El tráfico localizado es demasiado pequeño para obtener un resultado fiable en un plazo razonable, en cuyo caso realizar pruebas en el mercado de origen e implementar el modelo ganador es la vía más rápida.

Lista de verificación de evaluación: preguntas que debe hacer antes de realizar pruebas A/B en un sitio traducido.

¿El proxy traduce el texto que un script de prueba escribe en la página luego de cargar?
Pregunte cómo se registran los cambios que se realizan en el navegador. Smartling documenta que DCS intercepta las escrituras DOM, como innerHTML y textContent, y captura contenido de terceros; confirme en una prueba piloto que se detectan las variantes de su herramienta de prueba.

¿Cuánto tiempo transcurre entre la publicación de una traducción y su visualización por parte de los visitantes?
Consigue el número en minutos, porque así determina tu tiempo de lanzamiento. Para contenido capturado por DCS, la cifra puede ser de hasta 20 minutos (Smartling Help Center, "Dynamic Content Support (DCS) para el GDN").

¿Qué ven los visitantes locales antes de que se traduzca una variante?
La respuesta segura es una traducción automática provisional, no texto en el idioma fuente. Pregunta si ese recurso también cubre contenido dentro del navegador.

¿Puede una prueba identificar, excluir o variar según el idioma?
Busca una señal de idioma que tu servidor o CMS pueda leer, como la cabecera X-Language-Locale, y una forma de cambiar la copia por zona, como los intercambios de contenido.

¿Se enrutarán automáticamente las variantes de cadenas para la traducción?
Pregunte si las nuevas cadenas se pueden filtrar en trabajos por página o por fuente de captura. En Smartling, las cadenas capturadas por DCS llevan un prefijo /origin-pjs/ que las reglas de automatización de trabajos pueden emplear para filtrar.

¿Cómo se relacionan los números de tráfico proxy con mis análisis?
Los conteos de solicitudes proxy y las vistas de página de analítica miden cosas diferentes, así que espera que sean diferentes; la conciliación se explica por qué los conteos de solicitudes proxy de traducción no coinciden con Google Analytics.

¿Puede mi servidor seguir viendo quién es el visitante?
La segmentación del lado del servidor necesita la IP y el protocolo real del visitante. La GDN pasa los encabezados X-Forwarded-For y X-Forwarded-Proto al sitio fuente precisamente por esta razón.

¿Cómo mantiene Smartling traducidas las variantes de las pruebas A/B?

La Red Global de Entrega (GDN) de Smartling empareja un proxy de traducción con el Soporte de Contenido Dinámico (DCS), y entre ambos gestionan tanto las variantes renderizadas en tu servidor como las variantes renderizadas en el navegador. Las variantes que renderiza tu servidor se traducen en tránsito mediante el proxy, que agrega aproximadamente 40 milisegundos por solicitud localizada de media. Las variantes que un script de prueba escribe en el navegador son capturadas por DCS, que monitoriza la página en busca de texto nuevo o cambiado, la comprueba con un archivo de traducción de traducciones publicadas y envía cualquier cosa nueva a tu proyecto GDN; DCS está activado por defecto para proyectos GDN creados luego de agosto de 2023 (Smartling Help Center, "Dynamic Content Support (DCS) para GDN").

Alrededor de esos dos mecanismos se encuentran los controles que necesita un programa de pruebas. El encabezado X-Language-Locale indica a tu servidor para qué idioma es cada solicitud, por lo que las pruebas del lado del servidor pueden ser dirigidas por mercado, y X-Forwarded-For preserva la IP del visitante para geosegmentación. Los intercambios de contenido cambian el texto o HTML en una sola zona, las reglas de No traducir y el atributo translate="no" mantienen las variantes dentro del idioma fuera de la traducción, y el TM a nivel de sitio muestra una traducción automática provisional para cualquier cadena de variantes aún en revisión. Las cadenas capturadas por DCS aparecen en el mismo proyecto GDN como contenido proxy, por lo que la misma memoria de traducción, glosario y Reglas de Automatización de Trabajos se aplican al copy de prueba que al resto del sitio.