Què fa realment Segment

El Segment SDK (carregat des de cdn.segment.com/analytics.js) inicialitza un objecte global analytics i identifica els visitants amb una galeta propietat de Segment anomenada ajs_anonymous_id. El codi de l'aplicació crida analytics.identify(), analytics.track(), analytics.page() i analytics.group(), i el SDK remet cada crida al punt d'ingesta de Segment. Des d'allà, Segment distribueix l'esdeveniment — en temps real o per lots — a qualsevol destinació habilitada a la font: Google Analytics, Facebook Pixel, Customer.io, Iterable, Amplitude, Mixpanel, Snowflake, BigQuery i desenes d'altres.

Cada reenviament a una destinació posterior és una activitat de tractament separada des de la perspectiva del GDPR. La base legal per enviar l'esdeveniment a Google Analytics no és la mateixa base legal que enviar el mateix esdeveniment a Customer.io, ni la mateixa que escriure el mateix esdeveniment en un magatzem de Snowflake. Un bàner de consentiment que registra un únic "accepto el màrqueting" no pot autoritzar legítimament tots ells per si sol, llevat que la categorització de les destinacions coincideixi amb la categorització del consentiment.

Primitius de consentiment natius de Segment

Segment ha invertit considerablement en primitius de gestió de consentiment durant els darrers dos anys. A partir del 2026, la plataforma exposa tres superfícies significatives per a l'aplicació del consentiment.

Consent Management (antigament Consent Stamping)

La funció Consent Management us permet adjuntar una càrrega de consentiment a cada esdeveniment que Segment ingereix. La càrrega registra quines categories de tractament ha acceptat l'usuari — normalment la cadena IAB TCF v2.3, la cadena GPP o una categorització personalitzada de Segment. Les destinacions posteriors es poden configurar per reenviar o bloquejar en funció de l'estat de consentiment de cada esdeveniment.

Filtres de destinació amb control d'accés per consentiment

Els filtres de destinació us permeten escriure una petita expressió JavaScript o Lua que s'executa a cada esdeveniment abans de ser reenviat a una destinació específica. El filtre pot inspeccionar la càrrega de consentiment i interrompre el reenviament si no s'ha concedit la categoria pertinent. Aquest és el primitiu adequat per a l'aplicació detallada del consentiment per destinació.

La configuració d'integrations a nivell de font

Per a un control més groller, l'objecte integrations a nivell de font pot deshabilitar destinacions completament per a cada esdeveniment: analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } }). Això és útil per al cas tot-o-res, però no gestiona bé la granularitat a nivell de categoria.

Integració de CMP pas a pas

L'arquitectura fiable consisteix a mapear les decisions de categories del CMP a la categorització de destinacions de Segment, adjuntar la càrrega de consentiment a cada esdeveniment i utilitzar filtres de destinació per aplicar el control d'accés per destinació.

1. Categoritzeu les destinacions

Reviseu la llista de destinacions habilitades al vostre espai de treball de Segment i assigneu cadascuna a una categoria de CMP. Les destinacions com Google Analytics, Mixpanel i Amplitude solen ser analítiques. Les destinacions com Facebook Pixel, TikTok i Pinterest solen ser de màrqueting. Les destinacions com Snowflake o BigQuery (el vostre propi magatzem) solen ser necessàries o funcionals — però només si les analítiques processades aigües avall del magatzem també estan categoritzades correctament. Documenteu aquest mapeig en algun lloc revisable; la defensa en l'auditoria hi descansa.

2. Retardeu la inicialització del SDK fins que es capturi la decisió de consentiment

El Segment SDK es pot configurar per no enviar esdeveniments fins que es cridi analytics.load(). Retardeu la crida de càrrega fins que el CMP hagi capturat la decisió de l'usuari, perquè no es disparin esdeveniments abans del consentiment. Alternativament, utilitzeu el patró de cua analytics.ready() amb control d'accés per consentiment als propis gestors d'esdeveniments.

3. Adjunteu la càrrega de consentiment a cada esdeveniment

Configureu la funció Consent Management per estampar la cadena TC d'IAB, la cadena GPP o la vostra categorització personalitzada a cada esdeveniment ingerit. L'estampació viatja amb l'esdeveniment a través del pipeline de Segment i està disponible per als filtres de destinació.

4. Escriviu filtres de destinació per a l'aplicació a nivell de categoria

Per a cada destinació, escriviu un filtre que comprovi la càrrega de consentiment amb la categoria que requereix aquella destinació. Si l'usuari ha acceptat el màrqueting però ha rebutjat les analítiques, les destinacions de la categoria de màrqueting reben l'esdeveniment i les destinacions de la categoria d'analítiques es descarten silenciosament. La lògica del filtre normalment llegeix de event.context.consent.categoryPreferences o el camí equivalent en l'esquema de la càrrega de consentiment.

5. Propageu les revocacions

Quan l'usuari revoca el consentiment, dues coses han de succeir: el SDK deixa d'enviar nous esdeveniments sota les categories revocades (gestionat pel commutador d'integrations a nivell de font), i el perfil d'usuari existent a les destinacions posteriors ha de ser actualitzat o eliminat. La Privacy API de Segment admet tant sol·licituds d'eliminació com indicadors de supressió; configureu el CMP per cridar el punt final de Privacy API adequat en la revocació.

Errors comuns

Quatre errors d'integració expliquen la majoria de les troballes d'auditoria en els desplegaments de Segment.

Tractar Segment com un únic rastrejador

El defecte més comú: tancar Segment sota una única categoria (normalment analítica) i suposar que això satisfà tot el que hi ha aigües avall. No ho fa. Si Facebook Pixel està habilitat com a destinació, l'esdeveniment reenviat a Facebook requereix consentiment de la categoria de màrqueting, no d'analítiques. La categorització per destinació és obligatòria.

Oblidar la destinació del magatzem

Molts equips habiliten Snowflake o BigQuery com a destinació de Segment i tracten el magatzem com exempt perquè "és infraestructura interna". El propi magatzem pot ser intern, però el tractament posterior — taulers de BI, modelatge de públics similars, segmentació de clients — alimenta funcions de màrqueting i analítiques. La categorització de consentiment del magatzem hauria de reflectir l'ús més permissiu al qual fluïen eventualment les dades del magatzem.

Fonts del costat del servidor sense context de consentiment

Segment admet fonts del costat del servidor (el vostre backend crida Segment directament). Els esdeveniments d'aquestes fonts no hereten automàticament l'estat de consentiment del costat del navegador. L'aplicació ha de cercar l'estat de consentiment de l'usuari en el moment d'emissió de l'esdeveniment i adjuntar-lo a la crida. Sense això, els esdeveniments del costat del servidor eludeixen completament el CMP.

Ignorar la fusió d'identitats entre fonts

La resolució d'identitats de Segment fusiona perfils anònims i identificats, i pot fer-ho entre fonts web, mòbils i del costat del servidor. Si l'estat de consentiment difereix entre aquestes superfícies, el perfil fusionat hereta la interpretació més permissiva per defecte. Configureu la resolució d'identitats per utilitzar l'estat de consentiment més restrictiu, no el més permissiu, entre les identitats fusionades.

Llista de verificació d'auditoria

Sis preguntes concretes a respondre per a qualsevol desplegament de Segment que toqui trànsit de EU, UK o Califòrnia.

• Està documentada la categorització de les destinacions? Per a cada destinació habilitada, hi ha un registre escrit de quina categoria de CMP la controla?
• El SDK espera el consentiment? Obriu la pàgina en una finestra privada i confirmeu que no es disparen crides a analytics.track cap a api.segment.io abans que s'accepti el bàner.
• S'estampen les càrregues de consentiment a cada esdeveniment? Inspeccioneu una mostra d'esdeveniments ingerits al depurador de Segment i confirmeu que la càrrega de consentiment és present i completa.
• Els filtres de destinació respecten les categories? Confirmeu que deshabilitar una categoria al CMP fa que no es reenvien esdeveniments a les destinacions d'aquella categoria.
• Les fonts del costat del servidor porten el consentiment? Confirmeu que les crides del costat del servidor busquen i adjunten l'estat de consentiment actual de l'usuari en el moment de l'emissió.
• Es dispara la Privacy API en la revocació? Confirmeu que les revocacions iniciades pel CMP criden l'API de supressió o eliminació de Segment, no només l'exclusió voluntària local del SDK.

On encaixa Segment en una pila orientada al consentiment

Les CDP ocupen la posició més privilegiada en l'arquitectura de privadesa: una única decisió al bàner del CMP ha de propagar-se a desenes de destinacions posteriors, cadascuna amb la seva pròpia postura legal. L'arquitectura adequada tracta el CMP com la font de veritat per a les preferències de categoria de l'usuari, adjunta aquella veritat a cada esdeveniment que Segment ingereix i utilitza els primitius de filtres de destinació de Segment per aplicar el control d'accés a nivell de categoria a la capa d'enrutament en lloc de a cada destinació individual. Feta correctament, el treball d'enginyeria s'escala linealment amb el nombre de destinacions — afegir una nova destinació és una decisió de categorització i una regla de filtre, no una nova integració. Feta incorrectament, el CDP es converteix en un multiplicador de privadesa, reenviant esdeveniments que violen el consentiment a una llarga cua de socis més ràpid del que cap auditoria manual pot arribar a seguir.