Si trabajas en Desarrollo de Apps, tarde o temprano te toca vivir este momento: alguien mira el panel, ve que “bajó el ROAS”, que “subió el CPA” o que “no se puede atribuir bien” y automáticamente concluye que el marketing ya no funciona. Y ahí empieza la cadena de malas decisiones: pausar campañas que sí aportaban ventas, duplicar presupuesto donde solo hay atribución “bonita”, o cambiar creatividades cada 48 horas intentando arreglar con anuncios un problema que está dentro de la app.
SKAdNetwork no vino a “romperlo todo”. Vino a forzarnos a medir de otra manera: menos obsesión por la precisión quirúrgica del usuario individual, más foco en señales agregadas, calidad real y experimentos que demuestran impacto. Si aceptas ese cambio de mentalidad, puedes seguir creciendo en iOS con control. Si intentas replicar el tracking de antes como si nada hubiera pasado, vas a jugar a adivinar… y adivinar con presupuesto suele salir caro.
Lo que buscamos en esta guía es exactamente eso: que entiendas cómo funciona SKAdNetwork (sin convertirlo en una clase aburrida), que sepas por qué tu reporting “se siente raro” y, sobre todo, que tengas un hilo conductor para tomar decisiones que no dependan de un único dashboard.
El cambio de juego: cuando la atribución dejó de ser una verdad absoluta
Durante años nos acostumbramos a una narrativa muy cómoda: “este anuncio → este clic → este usuario → esta compra”. Esa cadena se convirtió en religión. El problema es que esa “verdad” ya era imperfecta incluso antes de iOS: había usuarios multi-dispositivo, bloqueadores, ventanas de atribución caprichosas y modelos distintos por plataforma. Con privacidad, simplemente se hizo más visible lo que siempre fue cierto: la atribución no es la realidad, es una aproximación.
La realidad es tu negocio: cuántas compras entran, cuántas suscripciones se mantienen, cuántos leads acaban cerrando. La atribución intenta repartir mérito, y SKAdNetwork lo hace bajo reglas que protegen al usuario. Eso significa menos granularidad, más retraso y más agregación. Y sí: al principio duele, porque te quita esa sensación de control inmediato. Pero también te obliga a madurar: a definir mejor el funnel, a instrumentar eventos con criterio y a apoyarte en datos propios.
En Bolmia lo vemos mucho: cuando un equipo pasa de “optimizar por el numerito del día” a “optimizar por dirección correcta y resultados reales”, se vuelve menos reactivo, más estratégico y, paradójicamente, mejora performance. Porque deja de perseguir espejismos.
Qué es SKAdNetwork en la práctica (y por qué no debes tratarlo como un pixel)
SKAdNetwork (SKAN) es el framework de Apple para atribuir instalaciones y conversiones de forma respetuosa con la privacidad. En lugar de identificar usuarios, emite postbacks agregados que informan a la red publicitaria (y a tu sistema) de que ocurrió una instalación atribuible y, si tu configuración lo permite, un valor que resume el “progreso” del usuario en una ventana de tiempo.
Lo importante aquí no es memorizar la teoría, sino entender la sensación que genera: vas a ver conversiones “llegar tarde”, vas a tener menos detalle por campaña y vas a notar diferencias entre lo que reporta la plataforma publicitaria y lo que ves en tu backend. No significa que tu medición esté rota. Significa que el sistema está diseñado para no exponer identidad.
Y esto tiene una implicación enorme: si antes tu stack era “instalo un SDK y ya está”, con SKAN tienes que pensar más como si estuvieras diseñando un sistema de medición propio. Es decir: ¿qué me interesa medir? ¿qué señales predicen valor? ¿cómo traduzco eso a un modelo agregable?
Cuando hacemos desarrollo de aplicaciones móviles con foco en crecimiento, esta parte se vuelve tan importante como el diseño del onboarding. Porque lo que no mides bien, lo optimizas mal. Y lo que optimizas mal, te cuesta dinero o tiempo.
El norte no es SKAN: el norte es tu KPI (y todo lo demás son señales)
Antes de elegir eventos, SDKs o dashboards, necesitas un KPI norte. Uno. Si intentas “optimizar todo”, acabas optimizando nada. En una app de suscripción, casi siempre el KPI norte real es pago (o trial que termina en pago). En ecommerce, compra. En lead gen, lead cualificado (no “form enviado” si luego no cierra nadie).
Una vez definido el norte, recién ahí eliges señales intermedias. Aquí suele pasar la primera pelea interna: marketing quiere señales rápidas (installs, registros), producto quiere señales de uso (tiempo, pantallas), y negocio quiere revenue. La solución no es escoger una sola: es ordenar el funnel en una secuencia lógica.
Un ejemplo típico: en apps de suscripción, “trial iniciada” suena bien, pero no siempre predice pago. A veces predice curiosidad. En cambio, “trial iniciada + onboarding completado + interacción con feature clave” suele ser mucho más consistente como señal de calidad. En ecommerce, “add to cart” puede ser débil; “checkout iniciado” suele estar más cerca del dinero real.
Aquí empieza lo útil: SKAN te da una ventana de tiempo donde puedes “codificar” ese progreso. Si tú defines bien el progreso, SKAN se vuelve una herramienta. Si defines progreso con eventos vacíos, SKAN se vuelve ruido.
Cómo pensar el conversion value como una historia (no como una lista de eventos)
La forma más sana de diseñar conversion values es imaginar que estás contando la historia del usuario en las primeras etapas: llegó, entendió, activó, mostró intención y (con suerte) compró. Esa historia necesita pocos hitos, pero hitos relevantes.
El error que vemos repetirse: equipos que meten demasiados eventos “porque se puede”, y terminan con un Frankenstein que no distingue usuarios buenos de malos. O al revés: equipos que codifican solo una conversión final y pierden la oportunidad de optimizar por señales tempranas mientras que tu quieres activar usuarios desde cualquier canal.
Una secuencia simple suele funcionar:
- Primer paso: instalación y apertura.
- Luego: registro o primer “aha moment”.
- Después: acción clave que se correlaciona con valor (por ejemplo, crear el primer proyecto, subir el primer documento, completar el primer entrenamiento, etc.).
- Finalmente: intención fuerte (checkout iniciado, trial iniciada con onboarding completo, plan seleccionado).
No necesitas que SKAN te diga “compró el usuario Juan”. Necesitas que te diga “esta campaña está trayendo usuarios que llegan a la intención fuerte más que esta otra”. Esa comparación, aunque sea agregada, sigue siendo accionable.
En proyectos de programación de aplicaciones móviles, este diseño se traduce en instrumentación consistente: eventos bien nombrados, propiedades útiles cuando corresponda y, sobre todo, lógica clara de cuándo actualizas el valor. La claridad aquí evita que tu analista termine interpretando humo.
Por qué tu reporting se ve diferente: retrasos, ventanas y deduplicación
Hay un momento inevitable: implementas SKAN, miras el panel, y sientes que todo “va lento”. No es tu imaginación. Los postbacks no están diseñados para ser instantáneos. Además, cada plataforma tiene su forma de presentar esos datos. Por eso es normal que veas discrepancias entre redes publicitarias, MMP y tus números internos.
Aquí la recomendación más práctica es cambiar el hábito de análisis. En lugar de tomar decisiones diarias (sobre todo si tu volumen no es enorme), trabaja con ventanas semanales o quincenales para evaluar tendencias. Si el presupuesto es alto y hay mucho volumen, puedes afinar más, pero incluso así: no te cases con “lo de ayer”.
También pasa algo muy típico: un cambio de creatividad o de segmentación “parece” hundir el ROAS, pero en realidad lo que ocurrió es un desfase de atribución. A los 7–10 días, la tendencia se corrige. Pero muchos equipos ya tomaron decisiones drásticas en el día 2. Esa reactividad es lo que más dinero quema en iOS actualmente.
La medición madura: combinar SKAN con datos propios para tener una “fuente de verdad”
Si dependes solo de lo que te dice una red publicitaria, estás encerrado en su modelo. Si dependes solo del MMP, puedes perder contexto de negocio. La forma más robusta que aplicamos en Bolmia es construir una “fuente de verdad” con datos propios: ingresos reales, retención, renovaciones, cancelaciones, calidad de lead, etc.
No hace falta montar un monstruo de data warehouse el día uno. Pero sí necesitas una capa donde puedas responder preguntas como:
- ¿Cuánto revenue real entró por cohorte semanal?
- ¿Qué campañas o fuentes parecen correlacionarse con usuarios que llegan a intención fuerte?
- ¿Qué pasa después del día 7, día 14, día 30?
Cuando conectas eso con SKAN, empiezas a ver patrones útiles. SKAN te da dirección y señales tempranas; tu backend te confirma el valor real. Esa combinación es mucho más estable que intentar “forzar” atribución perfecta.
Aquí encajan estrategias como desarrollo iOS y Android con un enfoque coherente: aunque Android tenga más señal disponible, conviene unificar medición para no depender de un solo sistema. En entornos multiplataforma, esto es oro para comparar y decidir.
Incrementality: la pregunta que de verdad importa cuando la atribución es borrosa
Cuando la atribución pierde precisión, la pregunta más valiosa no es “¿quién se llevó el crédito?”, sino “¿esto genera resultados adicionales o solo redistribuye atribución?”. Esa es la esencia de incrementality.
Lo bonito de incrementality es que no depende de saber exactamente quién es quién. Depende de comparar escenarios. Por ejemplo: apagas campañas en una región durante un periodo controlado y comparas qué pasa con ventas. O haces un holdout (dejas un porcentaje sin exposición) y mides diferencia.
No necesitas hacerlo perfecto para que sea útil. Incluso experimentos sencillos te protegen de errores clásicos: campañas que se ven “increíbles” en el panel pero no mueven ingresos, o campañas que el panel “castiga” y, sin embargo, sostienen el negocio.
En iOS actual, incrementality es un superpoder. Te devuelve el norte cuando la atribución te distrae.
Creatividad y mensaje: el lugar donde se gana (o se pierde) performance en iOS
Con menos tracking, la creatividad pesa más. Porque cuando no puedes micro-optimizar por usuario individual, tu mejor palanca es atraer al usuario correcto con el mensaje correcto. Y esto no va solo de “hacer anuncios bonitos”. Va de alinear expectativa con experiencia.
Si tu anuncio promete “ahorra tiempo en 5 minutos”, tu onboarding debe entregar ese “aha moment” rápido. Si tu anuncio vende precio, tu paywall no puede esconderlo o hacerlo confuso. Si tu anuncio vende resultados, la app debe mostrar progreso tangible.
Hemos visto campañas “quemar presupuesto” porque el anuncio trae curiosos, no usuarios valiosos. Y eso se nota cuando miras señales tempranas bien definidas. Aquí es donde SKAN, bien diseñado, ayuda: no para saber quién compró, sino para saber si estás atrayendo calidad.
Y cuando hace falta, una decisión de producto mueve más que diez cambios de segmentación. Ajustar un flujo, reducir fricción, mejorar copy del paywall o acelerar la carga impacta más que pelearte con dashboards.
Onboarding, paywall y retención: el performance que nadie quiere mirar… hasta que es tarde
Si tu app convierte mal, el problema rara vez es “falta de installs”. Muchas veces es fricción: demasiados pasos, permisos demasiado pronto, promesa poco clara, paywall agresivo, o simplemente falta de valor percibido antes de pedir acción.
Esto aplica tanto en desarrollo nativo de apps como en enfoques más rápidos como desarrollo híbrido de apps o desarrollo multiplataforma: puedes tener una arquitectura distinta, pero la lógica de conversión es la misma. Si el usuario no entiende el valor, no se queda. Si no se queda, el ROAS sufre.
Y aquí se conecta todo: SKAN te obliga a medir mejor señales tempranas, lo que te obliga a mirar onboarding con lupa, lo que te lleva a mejoras de UX que suben conversión. Es casi un ciclo virtuoso si lo abrazas.
También es donde entran funcionalidades específicas que suelen mover aguja en apps de consumo: apps con notificaciones push (bien usadas, no spam), apps con compras in-app (bien instrumentadas, sin fricción) y apps con analítica y tracking (para entender comportamiento real, no solo atribución).
Cómo se ve un plan realista para “medir y optimizar” sin entrar en caos
En Bolmia solemos aterrizar esto como un camino progresivo, porque intentar hacerlo todo a la vez suele matar el proyecto. Primero ponemos orden en medición mínima viable: eventos clave, definición de activación, y alineación de KPI norte. Luego diseñamos conversion values con lógica de negocio. Después conectamos data propia para validar revenue y retención. Y recién ahí escalamos experimentos e incrementality para tomar decisiones con seguridad.
Es un enfoque que funciona tanto si estás lanzando una app desde cero como si ya tienes inversión fuerte y lo que necesitas es recuperar claridad. Porque el objetivo no es “tener el dashboard más completo”. El objetivo es tomar mejores decisiones que la competencia.
Preguntas frecuentes
1) ¿SKAdNetwork reemplaza por completo la atribución tradicional?
No. Cambia el enfoque: menos detalle por usuario y más señales agregadas. Sirve para orientar optimización, pero conviene validarlo con datos propios.
2) ¿Por qué mis conversiones “aparecen tarde”?
Porque los postbacks tienen retrasos y ventanas. Esto es normal en SKAN: analiza por periodos (7–14 días) y evita decisiones reactivas.
3) ¿Cómo elijo eventos para conversion values?
Escoge hitos que predigan valor: activación real, intención fuerte y acciones clave. Menos eventos, mejor elegidos, suele ganar.
4) ¿Necesito un MMP sí o sí?
No siempre, pero ayuda si trabajas con varias redes y quieres orden. Si tienes poco volumen, empieza simple y escala cuando lo necesites.
5) ¿Qué es incrementality y por qué importa aquí?
Es medir impacto real (ventas “extra”) con tests tipo holdouts o geo-tests. Te protege cuando la atribución no es 100% precisa.
