La migración al server-side debe progresar gradualmente, socio por socio. El objetivo es disponer de tiempo para «probar y aprender» y trabajar en la calidad de los datos.
No, optar por el server-side no significa que haya que migrar a toda prisa a todos los socios. Al contrario, todo converge hoy en día para incitar a las empresas a seguir un enfoque progresivo. Hay al menos dos razones para ello. En primer lugar, los socios están lejos de estar preparados para una implantación de etiquetas en el servidor. En segundo lugar, es muy recomendable darse tiempo para aprender.
Como resultado, al menos durante los próximos meses, la gestión de etiquetas no será ni totalmente del client-side ni totalmente del server-side, sino… híbrida. ¿Cómo proceder? En primer lugar, preparando su organización para el server-side. A continuación, siga estos pasos para su implantación.
Paso 1: Elija su arquitectura
Hoy en día existen dos métodos posibles para implementar una colección del server-side: Las API y la «etiqueta maestra»; tenga en cuenta que estos dos métodos pueden combinarse. El primero consiste en utilizar las API del servidor proporcionadas por una plataforma como Commanders Act para transmitir todos los eventos previstos en el contexto de sus casos de uso. Para ello, tómese el tiempo de catalogar sus eventos para cada uno de estos casos.
En cuanto al método de la «etiqueta maestra», se llama así porque, incluso en el server-side, implica el depósito de una etiqueta – pero sólo una etiqueta. Es esta etiqueta la que recoge todos los eventos requeridos por sus escenarios dentro del navegador con el fin de comunicarlos a la solución del server-side para su procesamiento.
Aquí hay que tomar una precaución: esta etiqueta debe depositarse en modo first-party. De lo contrario, navegadores como Safari o Firefox (y Chrome el año que viene) inhiben esta etiqueta, lo que conduce a la pérdida de datos .
Afortunadamente, mediante el proceso de delegación de subdominios, es muy posible colocar la etiqueta maestra Commanders Act como etiqueta first-party.
Paso 2: Trabajar en la calidad de los datos
Esta etapa debe ser objeto de toda la atención. Los datos recopilados a través del servidor representan su «centro de datos»: la base de datos en la que se basarán las activaciones de sus socios. También es el momento adecuado para revisar la capa de datos y el catálogo de eventos que se van a integrar. El objetivo es mejorar la recogida de datos, por supuesto, pero también anticipar el despliegue de nuevos casos de uso.
Este trabajo debe ser una oportunidad para «recibir los datos». Hay dos objetivos: en primer lugar, garantizar que el consentimiento se propague correctamente para que la información difundida a los distintos socios se ajuste a las preferencias del usuario. En segundo lugar, asegurarse de que los datos están normalizados y, por tanto, formateados para que puedan utilizarse.
Por ello, Commanders Act ofrece varias herramientas (calidad de los datos de origen o inspector de eventos en directo) para recibir los datos enviados al centro de datos y comprobar su calidad. Este trabajo puede realizarse en tiempo real y la plataforma proporciona las herramientas necesarias, en particular con una función de «limpieza de datos» que permite corregir automáticamente los datos erróneos antes de enviarlos a los socios.
Dedicar tiempo a trabajar en la calidad de los datos es a la vez un requisito previo y una ventaja. Un requisito previo porque, sin datos de calidad, el mecanismo del server-side se atasca rápidamente. Un beneficio, porque esta mayor calidad también genera activaciones más precisas y, por tanto, un retorno tangible del esfuerzo y campañas más eficaces.
Paso nº 3: Migrar un primer socio
¿Se ha acordado el método de recogida? ¿Se ha trabajado con los datos? Ha llegado el momento de migrar a un primer socio, a ser posible un «buen candidato», es decir, un socio que haya documentado bien el proceso de migración. Es el caso, por ejemplo, de Facebook, que, como otros, recomienda conservar los dos flujos de datos, del client-side (procedentes del píxel clásico) y del server-side (procedentes de la «API de conversión»), durante un periodo de observación.Este periodo servirá para controlar la calidad de los datos distribuidos. Para ello, Commanders Act ofrece varias herramientas de supervisión y alerta en su plataforma, para que este trabajo de «prueba y aprendizaje» pueda realizarse con tranquilidad.
Una vez desplegado el conector del server-side , es necesario un periodo de observación -digamos dos semanas- para garantizar que no se produce ninguna interrupción del servicio. Tras este periodo, la etiqueta del client-side puede desactivarse para conservar únicamente la activación del server-side.
La buena noticia es que este trabajo beneficia mecánicamente a los demás socios y, por tanto, contribuye a acelerar las migraciones posteriores. Aproveche el catálogo de destinos de Commanders Act y planifique estas migraciones.
Para culminar con éxito la migración del server-side, no te encierres en un sistema de gestión de proyectos presionado por los plazos. Priorice la migración de los socios en función de los imperativos de su empresa e implique a los equipos de medios en las distintas etapas del proyecto. Sobre todo, dése tiempo para trabajar en la calidad de sus datos y probar las implantaciones, socio por socio. Sus datos merecen este tiempo y esta atención.
¿Por qué el server-side se convertirá en su mejor aliado? Descúbralo en nuestro libro blanco.
