Cómo leer una cadena de redireccionamientos

Los saltos, a grandes rasgos, en el orden en que los encontrarás

Un anuncio de búsqueda de marca casi nunca enlaza directamente a una página de destino. Enlaza a un redireccionamiento, que envía el navegador a otro redireccionamiento que, finalmente, tras entre uno y cuatro saltos, aterriza en algún lugar donde un comprador realmente puede adquirir algo. Conocer la forma de esa cadena antes de investigar te evita confundir el salto equivocado con toda la historia.

El primer salto, en Google, suele ser el rastreador de clics del propio motor de búsqueda: una URL en un dominio de publicación de anuncios de Google que lleva un parámetro gclid. Ese gclid pertenece a Google. Es la forma en que la propia plataforma publicitaria de Google atribuye el clic a la campaña que lo pagó, y no te dice absolutamente nada sobre quién es el anunciante ni sobre si es un afiliado. He visto a gente tratar un gclid como si fuera prueba de una identidad de afiliado. No lo es. Es un token interno de contabilidad de Google.

El segundo salto es donde empieza a ponerse interesante: un redireccionamiento a través del dominio de seguimiento de la red de afiliados, o en ocasiones el acortador de enlaces del propio afiliado situado delante de este. Este es el salto que normalmente, aunque no siempre, lleva el parámetro que identifica quién cobra.

A veces hay un tercer salto que no hace nada más que decidir a dónde debe ir realmente el cuarto salto, según algo sobre la solicitud: el país del visitante, su dispositivo, si su user agent parece un navegador real o un script. No todas las cadenas tienen este salto. Cuando está presente, vale la pena prestarle atención, por razones que explicaré más adelante.

El último salto es la propia página de destino del comerciante, la página desde la que un comprador realmente puede comprar. También es, de forma poco útil, la página que la mayoría anota cuando intenta documentar un problema, porque es la que se ve sin ningún esfuerzo adicional.

Dónde vive realmente el ID de afiliado

El nombre del parámetro es diferente en cada red y, a veces, en cada programa dentro de la misma red. He visto a_aid, subid, clickref, affid, y una docena de variantes opacas que son solo una cadena alfanumérica corta sin significado evidente hasta que la cotejas con los informes de la propia red. La mayoría de las redes con las que he trabajado usan algo de esta familia; yo no asumiría que uno específico aplica al tuyo sin verificar un enlace conocido y confiable de un afiliado que ya hayas aprobado.

utm_source es algo completamente distinto, y confundirlo con un ID de afiliado es el error más común que veo. Un parámetro utm es una convención de etiquetado que la persona que construye el enlace elige aplicar. No lo emite nadie, no lo verifica nadie y es trivialmente fácil de omitir, falsificar o copiar del enlace de otra persona. Trátalo como una pista como mucho, nunca como prueba de quién está ejecutando realmente un anuncio.

Aquí está la parte que hace tropezar a casi todos los que hacen esto por primera vez: el parámetro identificador normalmente vive en el segundo salto, el dominio de seguimiento de la red, no en la URL final. Para cuando la red redirige al comerciante, a menudo ya ha leído ese parámetro, lo ha registrado, ha dejado una cookie con la misma información y lo ha eliminado de la URL antes de enviar el navegador. La URL final de la página de destino, la que todo el mundo instintivamente copia y pega en un correo como "prueba", frecuentemente no lleva ningún rastro del afiliado.

Cómo se ve esto por escrito

Una cadena que vale la pena documentar se lee más o menos así, salto por salto, no resumida en una sola línea: el enlace del propio anuncio, una URL de googleadservices.com con el gclid de Google; luego un redireccionamiento a algo como track.[network].com/click?a_aid=4471&subid=coupon-hub-2; luego, si hay un salto de cloaking, una tercera URL que resuelve de forma distinta según quién pregunte; luego el dominio del comerciante, aterrizando en una página sin ningún parámetro de afiliado visible en su barra de direcciones.

El caso es la segunda línea. Todo lo anterior es contexto; todo lo posterior es donde una comprobación ingenua deja de buscar, lo cual es exactamente al revés. a_aid=4471 (o el parámetro y valor equivalentes en tu cadena) es lo que entregas a la red y les pides identificar. No la URL del comerciante. No el texto visible del anuncio. Ese parámetro, en ese salto.

Por qué la URL final por sí sola no prueba nada

Por esto, una captura de pantalla de solo la página de destino, con un pie como "miren quién se anuncia con nuestra marca", rara vez sobrevive a una conversación real con el equipo de cumplimiento de una red. Muestra que existió un anuncio y que se cargó una página. No muestra quién colocó el anuncio y, sin eso, no hay ID de socio que contrastar con un registro ni nada sobre lo que la red pueda actuar.

Necesitas toda la cadena, cada salto, con las querystrings completas intactas, no solo la última. En un navegador, eso significa abrir las devtools, activar "preserve log" en la pestaña de red antes de hacer clic en nada, y luego hacer clic en el anuncio y leer cada solicitud con un estado 301 o 302 en orden, anotando la URL completa de cada una. Desde una terminal, curl -sI -L sobre la URL del anuncio, leyendo una cabecera Location a la vez en lugar de seguir ciegamente hasta el final, hace más o menos el mismo trabajo para cadenas construidas enteramente sobre redireccionamientos HTTP.

Esa advertencia importa: no todos los saltos son redireccionamientos HTTP. Algunos son una etiqueta meta-refresh o un poco de JavaScript que establece window.location después de que la página ya se haya cargado, invisibles para una solicitud curl simple, que solo ve un 200 y deja de buscar. Si una cadena parece terminar antes de lo que esperarías, esa suele ser la razón, y necesitarás un navegador real, o una instancia con headless, para ver el resto.

Capturar pruebas que realmente sobrevivan a una discusión

Una marca de tiempo, al minuto, en una zona horaria que anotes en lugar de asumir. La secuencia completa de saltos, en orden, con las querystrings intactas, no resumida. Una captura de pantalla de la página de resultados de búsqueda que muestre el anuncio exactamente como se mostró. Una captura aparte de la página de destino a la que condujo. Ese es el estándar que he visto que espera el propio equipo de cumplimiento de una red antes de actuar ante una reclamación, y no es una barra alta una vez que sabes que hay que superarla; simplemente es una barra que casi nadie supera por casualidad.

Haz la captura desde un contexto de navegación ordinario: sin sesión iniciada, no desde una IP de oficina que haya estado buscando tu propio nombre de marca toda la semana, sin bloqueador de anuncios que reescriba silenciosamente la página antes de que hagas la captura. Estás intentando reproducir lo que un comprador anónimo vio realmente, y cualquier cosa que haga que tu solicitud parezca inusual es un motivo para que la otra parte argumente que la evidencia no refleja un clic real.

Las trampas que atrapan a la gente

Los redireccionamientos que comprueban la geografía o el dispositivo antes de decidir a dónde enviar el clic son la primera. Un anuncio que se comporta limpiamente desde una IP de escritorio en EE. UU. puede enviar a un visitante móvil en otro país a un lugar completamente distinto, a veces a una página sin ninguna marca, a veces a una página directamente encubierta construida para parecer inofensiva ante cualquiera que no sea la audiencia prevista. Si solo compruebas desde una ubicación y un dispositivo, solo estarás viendo una versión de una cadena que puede tener varias.

La segunda es más sutil: algunas cadenas se comportan de forma distinta para un navegador que nunca ha visitado antes frente a uno que lleva una cookie de una visita anterior, lo cual importa enormemente si estás recomprobando un caso una semana después de encontrarlo por primera vez y obtienes un resultado de aspecto más limpio la segunda vez. Eso no es el problema desapareciendo. Es muy posiblemente la cadena reconociéndote.

La tercera es la que yo mismo me he equivocado antes: asumir que el identificador que extrajiste nombra al afiliado, cuando muchas estructuras de red permiten que un afiliado de nivel superior ejecute subafiliados o sub-ID bajo su propia cuenta. El parámetro que sacaste de la cadena podría identificar a un pequeño editor que opera bajo el paraguas de otra persona, no al titular de la cuenta que naturalmente asumirías como responsable. Si esa distinción te importa depende de los términos de tu programa, pero vale la pena comprobarlo antes de nombrar a un socio específico en una reclamación, porque equivocarse en esto es el tipo de error que es difícil de deshacer con elegancia.

Esto es, mecánicamente, lo que automatiza una pasada de monitorización: seguir cada salto, extraer el parámetro, contrastarlo con un registro, antes de que algo llegue a la bandeja de entrada de una persona como caso terminado. Consulta cómo funciona para la versión más larga de ese flujo. Pero la versión manual de arriba vale la pena conocerla de memoria, hayas comprado algo o no, porque tarde o temprano necesitarás comprobar una cadena tú mismo, un fin de semana, sin esperar a un escaneo programado.

Admito que todavía abro las devtools y hago esto a mano ocasionalmente, en casos que se ven lo bastante inusuales como para no confiar del todo en un rastreo automatizado hasta que he visto los saltos ocurrir con mis propios ojos. Eso no es un demérito para la automatización. Simplemente, una cadena con un salto de cloaking es exactamente el tipo de cosa que vale la pena ver con tus propios ojos al menos una vez, para que sepas cómo es la normalidad cuando no la estás mirando.