Skip to main content
Un cartel tiene una sola URL. Cuando promocionas una app, esa URL tiene que enviar un iPhone a la App Store o a tu app, un teléfono Android a Play o a tu app, y a todos los demás a una página web. En UTMKit eso es un solo enlace con hasta tres destinos.

​
Desde la consola

Un enlace siempre tiene un destino web. Al lado puedes añadir un destino iOS y un destino Android, cada uno opcional e independiente.
  • Creando un enlace en el chat: dile al asistente la dirección de iOS o Android junto con el resto. Ver Crear un enlace.
  • Un enlace existente: abre Enlaces, elige Editar, y llena Destino iOS o Destino Android. Deja un campo vacío para quitarlo.
A partir de ahí un iPhone llega al destino de iOS, un teléfono Android al destino de Android, y todos los demás — una laptop, un bot que no se presenta como teléfono, un navegador que no podemos reconocer, un iPad que pide sitios web de escritorio — al destino web. Una plataforma que no configuraste cae de vuelta al destino web, nunca a la otra plataforma.

​
Qué puede ser un destino de plataforma

Solo una dirección https://: el propio enlace de tu app, o su página en la tienda en apps.apple.com o play.google.com. Un esquema de app propio como myapp:// se rechaza, por cuatro razones:
  1. No podríamos filtrarlo. Los destinos se revisan contra listas de abuso antes de convertirse en enlaces, y esas listas contienen direcciones web. Un esquema pasaría como “limpio” sin revisarse.
  2. No podríamos vigilarlo. La revisión diaria de destinos marca la dirección para ver que todavía responde. Un esquema no nombra ningún servidor al cual marcar.
  3. El teléfono decide qué app se abre. Si dos apps reclaman el mismo esquema, el sistema operativo elige una, no necesariamente la tuya.
  4. Un teléfono sin la app muestra un error. Una redirección a un esquema no tiene alternativa.
Una dirección de tienda en su forma de esquema (itms-apps://, market://) también se rechaza, y la consola nombra la forma https://, que abre la tienda en un teléfono y sigue funcionando en un escritorio.

​
Gobernado igual que el destino web

Un destino de plataforma se filtra con las mismas reglas y rechazos que el destino web, la revisión diaria lo vigila, y un cambio en él aparece en el registro de actividad. Tus UTM se aplican a los tres destinos; en una dirección de la tienda Play también se pliegan en el parámetro referrer de la tienda, así tu app sabe desde el primer inicio qué campaña trajo la instalación. La App Store no tiene un equivalente.

​
Los conteos

Abre el reporte y agrupa por destino. Cada fila nombra a dónde se envió a los visitantes — la App Store, Play, tu app, o la web — con su conteo, bajo los mismos filtros y exclusiones que cualquier otro agrupamiento. El informe para clientes, la API y el MCP también lo ofrecen.
Esto es enrutamiento más conteo, no atribución de instalación. Podemos decir cuántos teléfonos enviamos a Play; no podemos decir cuáles de ellos instalaron, ni que la persona que instaló es la misma que hizo clic. Eso necesita un SDK dentro de tu app, que un enlace corto no puede dar. Si tu app se abre o se muestra la página de la tienda depende de la dirección que elegiste y del teléfono de quien visita.
Los enlaces profundos están en todos los planes; una visita enrutada es un clic, medido como cualquier otro.

​
Desde la API y el MCP

Los destinos de plataforma son dos campos, ios_url y android_url, en POST /api/v1/links y PATCH /api/v1/links/{id}. Ambos aceptan solo una dirección https://, con los rechazos de arriba. En un PATCH, null (o un valor vacío) borra ese destino de plataforma; un campo que se omite queda como está. Ambas operaciones requieren el permiso links:write. Las herramientas MCP create_link y update_link (también links:write) hoy no reciben los campos de plataforma; configúralos por la API o la consola.