Si tu plataforma de engagement de clientes no tiene wallet passes nativos, tienes 2 caminos. Conectar una herramienta de pases y mantener 2 sistemas sincronizados, o migrar a una plataforma que emite pases de Apple y Google Wallet sobre el mismo perfil de cliente. El primero es más rápido para arrancar. El segundo es más simple de operar una vez que el wallet forma parte de tus journeys.

Escribimos esto para equipos que usan plataformas como Braze, OneSignal o CleverTap y quieren wallet passes sin desarmar todo. Para una vista por proveedor, revisa la comparación de Wallet passes.

Para startups y scaleups de LATAM, en México, Colombia, Argentina, Chile o Perú, la pregunta suele llegar justo cuando el equipo ya opera push, email y segmentos con un presupuesto ajustado. Por eso vale la pena decidir con números y no por inercia.

Desde dónde partes

El soporte de wallet varía mucho entre plataformas de engagement. Braze agrega wallet a través de partners como PassKit. OneSignal no tiene wallet passes nativos. Revisa la documentación actual de tu propia plataforma antes de planear, porque esto cambia.

Sin soporte nativo, el pase vive en 1 sistema y el cliente en otro. Cada pase que emites, actualizas o segmentas necesita datos de los 2.

Camino A: mantener tu CEP y sumar una herramienta de pases

Mantienes tu plataforma actual para push, email y segmentos, y conectas una herramienta de pases independiente para Apple y Google Wallet.

Así suele funcionar. Tu CEP o tu backend llama a la API de la herramienta de pases para emitirlos, muchas veces a través de webhooks. Si la herramienta de pases expone eventos, estos vuelven a tu CEP para que puedas segmentar a los holders.

La ventaja es real. No migras nada. Tu equipo conserva sus herramientas y journeys, y puedes empezar con 1 caso de uso, como una tarjeta de lealtad.

La desventaja crece con el tiempo. 2 bases de datos que sincronizar, 2 suscripciones, 2 revisiones de seguridad y GDPR. Cada escenario que combina una actualización del pase con un mensaje, como “tus puntos vencen pronto”, se arma entre 2 herramientas.

Piensa en una temporada como el Hot Sale en mayo o el Buen Fin en noviembre. Ahí es cuando el cupón en el wallet, el push y el email tienen que salir del mismo disparador a la misma hora, y cualquier retraso en la sincronización se nota en ventas.

Camino B: migrar a una plataforma con wallet nativo

Llevas tu mensajería a una plataforma que emite wallet passes de forma nativa, sobre el mismo perfil que push, in-app, email y SMS.

Los pases se emiten por User ID dentro de la plataforma. Segmentos, journeys y canales ven al holder del pase como 1 solo cliente. 1 paso del journey emite el pase y el siguiente envía el link.

Agregar el paso Issue wallet pass después de un disparador de entrada a una geozona en el constructor de Customer Journey de Pushwoosh

Obtienes 1 perfil, 1 journey y 1 contrato. Las actualizaciones del pase y los mensajes salen del mismo disparador, y no hay una capa de sincronización que vigilar.

El costo es la migración en sí: cambios de SDK, importación de datos, reconstrucción de journeys y plantillas. Vale la pena cuando el wallet es un canal de largo plazo, no una campaña de una sola vez.

Camino A: CEP + herramienta de pasesCamino B: wallet nativo
Tiempo hasta el primer paseRápidoDepende de la migración
Sistemas que mantener2 más una capa de sincronización1
Journeys con actualizaciones de pasesArmados entre 2 herramientas1 journey
Segmentar a los holdersCon datos sincronizadosMismo perfil
Contratos y evaluaciones de proveedor21
Ideal paraUn solo caso de uso de walletWallet como canal de retención
1 / 6
Tiempo hasta el primer pase
Camino A: CEP + herramienta de pases
Rápido
Camino B: wallet nativo
Depende de la migración
2 / 6
Sistemas que mantener
Camino A: CEP + herramienta de pases
2 más una capa de sincronización
Camino B: wallet nativo
1
3 / 6
Journeys con actualizaciones de pases
Camino A: CEP + herramienta de pases
Armados entre 2 herramientas
Camino B: wallet nativo
1 journey
4 / 6
Segmentar a los holders
Camino A: CEP + herramienta de pases
Con datos sincronizados
Camino B: wallet nativo
Mismo perfil
5 / 6
Contratos y evaluaciones de proveedor
Camino A: CEP + herramienta de pases
2
Camino B: wallet nativo
1
6 / 6
Ideal para
Camino A: CEP + herramienta de pases
Un solo caso de uso de wallet
Camino B: wallet nativo
Wallet como canal de retención
See Pushwoosh in action
Request a demo

Marco de decisión

Califícate con 4 preguntas.

  1. Alcance

    ¿El wallet es 1 campaña o un canal que vas a operar durante años? 1 campaña apunta al Camino A.

  2. Canales

    ¿Cuántos escenarios combinan un pase con push, email o SMS? Muchos apuntan al Camino B.

  3. Equipo

    ¿Tienes desarrolladores para construir y mantener una capa de sincronización? Si no, el Camino A se encarece con el tiempo.

  4. Residencia de datos

    ¿Necesitas hosting en la UE y menos encargados de tratamiento para GDPR? Cada proveedor extra es 1 encargado más que revisar.

Si 2 o más de tus respuestas son “largo plazo”, “muchos”, “sin desarrolladores” o “menos encargados”, mira con atención el Camino B. Si ninguna lo es, el Camino A es una opción perfectamente válida, y puedes revisarla en un año.

Cuánto cuestan 2 herramientas

El Camino A parece más barato el primer día, porque nada se mueve. En un año, suma las partes que nunca aparecen en la factura del proveedor de pases: construir la integración, mantener la sincronización, el trabajo duplicado en journeys y una segunda evaluación de proveedor.

El Camino B concentra el costo al inicio: el trabajo de migración y luego 1 sola cuota de plataforma. Compara los 2 en un horizonte de 12 a 24 meses, no de 1.

Para equipos de LATAM que tienen que justificar cada línea del presupuesto, conviene presentar esta comparación con el calendario comercial al lado: Hot Sale, Día de la Madre, CyberMonday, Buen Fin, Black Friday y Navidad. Cada temporada en la que armas el mismo journey en 2 herramientas es un costo que el Camino A repite.

Checklist de migración

Si eliges el Camino B, planea la migración alrededor del cliente, no de la herramienta.

  • Audita lo que envías. Haz la lista de campañas de push, email, SMS e in-app, journeys y segmentos que tienen que migrar.
  • Mapea tus datos. User IDs, tags, eventos y registros de consentimiento. El User ID es lo que une un pase con un cliente.
  • Configura el wallet una vez. Un certificado Pass Type ID de Apple (cuenta de Apple Developer, US$99 al año) y un Issuer ID de Google con la cuenta de servicio de Pushwoosh invitada a tu emisor. En LATAM, donde alrededor del 85% de los usuarios está en Android, el lado de Google no es un detalle.
  • Integra el SDK. Reemplaza el SDK anterior en tu app y prueba los push antes de mover el tráfico.
  • Reconstruye primero los journeys clave. Bienvenida, carrito abandonado, reactivación y después los nuevos escenarios de wallet.
  • Planea el lanzamiento de los pases. Emite pases desde un paso del journey y envía el link por email, SMS o push.
  • Opera en paralelo por poco tiempo. Mantén la plataforma anterior durante un breve traslape y después apágala.

Durante la migración, usa la API para emitir pases desde tu propio backend.

Simplifica tu stack con Pushwoosh

Pushwoosh emite pases nativos de Apple y Google Wallet sobre los mismos User ID, segmentos y journeys que push, in-app, email, SMS y WhatsApp. Es 1 sola plataforma, alojada en infraestructura propia en Alemania y Estados Unidos, con cumplimiento de GDPR y SOC 2 Type 2. Mira dónde encaja Pushwoosh entre las opciones de wallet.

Agregar wallet no debería significar sumar 1 herramienta más. Debería significar 1 perfil de cliente sobre el que todos los canales pueden actuar.

Conoce Wallet passes
Conoce Wallet passes

FAQ


Pushwoosh Team
Equipo de contenido en Pushwoosh
Compartir

Artículos relacionados

Ver todo