Prácticas recomendadas

Ten en cuenta las siguientes prácticas recomendadas cuando uses la API de Data Manager.

Envía todos los identificadores de usuario

Ya sea que envíes miembros del público o eventos con UserData, incluye tantos user_identifiers como sea posible, incluido el envío de varios identificadores del mismo tipo.

Por ejemplo, si tienes varias direcciones de correo electrónico para un usuario, incluye un elemento UserIdentifier independiente para cada dirección de correo electrónico. Del mismo modo, si tienes identificadores de diferentes tipos para un usuario, como direcciones de correo electrónico, números de teléfono y direcciones, agrega un UserIdentifier independiente para cada identificador, hasta el recuento máximo de identificadores.

Optimiza las solicitudes

Para reducir la probabilidad de superar los límites de solicitudes diarias, agrupa en lotes la mayor cantidad posible de elementos en cada solicitud, hasta los límites por solicitud.

Por ejemplo, si deseas agregar 10,000 miembros del público a un público, agrega a todos los 10,000 miembros en la lista audience_members en un IngestAudienceMembersRequest. Agrupar los 10,000 miembros en una sola solicitud es más eficiente que enviar una solicitud independiente para agregar a cada miembro del público.

Envía solicitudes simultáneas

Para reducir el tiempo total que se requiere para transferir datos, envía solicitudes simultáneas al IngestionService. Te recomendamos que envíes hasta 10 solicitudes de forma simultánea para reducir la probabilidad de superar el límite de solicitudes por minuto.

Puedes enviar solicitudes simultáneas incluso si tienen el mismo destinations.

Valida los datos en el cliente

La API de Data Manager usa un modelo de falla rápida. Si algún registro de una solicitud no pasa la validación síncrona, falla toda la solicitud y no se procesa ninguno de los registros. Además, la API valida las solicitudes en capas secuenciales, por lo que corregir un error podría revelar un error de una capa de validación posterior.

Para evitar viajes de ida y vuelta repetidos y solicitudes rechazadas, valida y limpia tus datos antes de enviarlos:

• Quita los valores vacíos antes de generar el hash: Verifica los campos como email_address y phone_number para detectar cadenas vacías o que solo contengan espacios en blanco antes de calcular los hashes SHA-256. La generación de un hash de una cadena vacía produce un hash válido que pasa las verificaciones de sintaxis, pero perjudica los porcentajes de coincidencias.

• Descarta los objetos compuestos incompletos: Asegúrate de que los objetos compuestos tengan todos los campos obligatorios antes de agregarlos a un registro. Por ejemplo, si a un objeto AddressInfo le falta alguno de sus cuatro campos obligatorios (given_name, family_name, region_code o postal_code), descarta todo el identificador address para evitar errores REQUIRED_FIELD_MISSING.

• Valida los campos de codificación y texto sin formato: Verifica que los campos con codificación hash coincidan con el encoding declarado en lugar de enviar texto sin formato sin procesar, y asegúrate de que los campos que deben permanecer como texto sin formato (como mobile_ids) no tengan codificación hash.

• Filtra las marcas de tiempo fuera de los límites: Asegúrate de que las marcas de tiempo no sean futuras ni más antiguas que la ventana de visualización de conversiones del destino.

  Si envías solicitudes con JSON, asegúrate de que las cadenas de marca de tiempo usen el formato RFC 3339 con una compensación de zona horaria.

• Limpia los números de teléfono: Verifica que los números de teléfono incluyan un código de país y usen el formato E.164 antes de generar el hash.

• Elimina los registros vacíos o de gran tamaño: Limita user_identifiers al límite por registro (10 identificadores), descarta los parámetros personalizados vacíos y omite cualquier registro que no contenga identificadores válidos.

• Verifica los requisitos de los casos de uso: Asegúrate de que cada evento incluya todos los campos obligatorios para su destino y caso de uso (como transaction_id para las conversiones en línea de Google Ads). Para obtener una lista completa de los campos obligatorios por caso de uso, consulta la guía de envío de eventos para tu destino en la Descripción general de los eventos.

• Usa validateOnly para probar las solicitudes: Envía solicitudes con validateOnly establecido en true para detectar errores de falla rápida sin transferir ni quitar datos. Una solicitud de solo validación exitosa no garantiza que no habrá errores durante el procesamiento asíncrono, por lo que debes seguir verificando el estado de la solicitud y los diagnósticos después de enviar una solicitud normal.

Para conocer las reglas detalladas de normalización y de aplicación de hash, consulta Cómo dar formato a los datos del usuario.

Verifica el estado de la solicitud y los diagnósticos

Captura y recopila el request_id de cada IngestAudienceMembersResponse o IngestEventsResponse, y usa los IDs de solicitud para verificar el estado y el diagnóstico de la solicitud.

Supervisa las cuotas y genera alertas sobre ellas

Para evitar rechazos de solicitudes inesperados, configura alertas de cuota y supervisión en la consola de Google Cloud. Supervisar el uso de la cuota te ayuda a hacer un seguimiento de los patrones de consumo y optimizar el procesamiento por lotes de solicitudes antes de que tu aplicación alcance los límites diarios o por minuto.

Implementar en producción

Cuando pases de las pruebas locales a las cargas de trabajo de producción, usa las credenciales predeterminadas de la aplicación con una cuenta de servicio adjunta o la federación de identidades para cargas de trabajo para autenticarte de forma no interactiva y segura.

Para obtener detalles sobre cómo configurar la autenticación en diferentes entornos de producción, consulta Implementa en producción.