O que Segment realmente fai

O SDK de Segment (cargado desde cdn.segment.com/analytics.js) inicializa un obxecto analytics global e identifica visitantes cunha cookie propiedade de Segment chamada ajs_anonymous_id. O código da aplicación chama analytics.identify(), analytics.track(), analytics.page(), e analytics.group(), e o SDK reenvía cada chamada ao punto final de inxestión de Segment. Desde alí Segment abanica o evento — en tempo real ou vía batch — a calquera destino que estea habilitado na fonte: Google Analytics, Facebook Pixel, Customer.io, Iterable, Amplitude, Mixpanel, Snowflake, BigQuery, e ducias de outros.

Cada envío a un destino posterior é unha actividade de procesamento separada desde a perspectiva de GDPR. A base legal para enviar o evento a Google Analytics non é a mesma base legal que enviar o mesmo evento a Customer.io non é o mesmo que escribir o mesmo evento nun almacén Snowflake. Un banner de consentimento que rexistra un único "Acepto marketing" non pode lexitimamente autorizar todos estes por si só a menos que a categorización de destinos coincida coa categorización de consentimento.

Primitivos de Consent Management nativos de Segment

Segment investiu fortemente en primitivos de xestión de consentimento nos últimos dous anos. A partir de 2026 a plataforma expón tres superficies significativas para a execución do consentimento.

Consent Management (anteriormente Consent Stamping)

A característica Consent Management permítelle adxuntar un payload de consentimento a cada evento que Segment inxire. O payload rexistra que categorías de procesamento aceptou o usuario — tipicamente a cadea de IAB TCF v2.3, a cadea GPP, ou unha categorización personalizada de Segment. Os destinos posteriores pódense configurar para reenviar ou bloquear baseándose no estado de consentimento en cada evento.

Filtros de destino con restrición de consentimento

Os filtros de destino permítenlle escribir unha pequena expresión JavaScript ou Lua que execútase en cada evento antes de que se reenvíe a un destino específico. O filtro pode inspeccionar o payload de consentimento e cortocircuitar o envío se a categoría relevante non foi concedida. Este é o primitivo correcto para execución de consentimento granular e por destino.

A configuración de integracións a nivel de fonte

Para un control máis groseiro, o obxecto de integracións a nivel de fonte pode desactivar destinos completamente nunha base por evento: analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } }). Isto é útil para o caso de todo ou nada pero non maneja ben a granularidade a nivel de categoría.

Integración de CMP paso a paso

A arquitectura fiable é mapear as decisións de categoría do CMP á categorización de destino de Segment, adxuntar o payload de consentimento a cada evento, e usar filtros de destino para executar a restrición por destino.

1. Categorizar destinos

Percorra a lista de destinos habilitados no seu espazo de traballo de Segment e asigne cada un a unha categoría de CMP. Destinos como Google Analytics, Mixpanel, e Amplitude son tipicamente analítica. Destinos como Facebook Pixel, TikTok, e Pinterest son tipicamente marketing. Destinos como Snowflake ou BigQuery (o seu propio almacén) son tipicamente necesarios ou funcionais — pero só se a analítica procesada aguas abaixo do almacén tamén se categoriza correctamente. Documente este mapeamento en algún lugar revisable; a defensa de auditoría descansa niso.

2. Diferir a inicialización do SDK ata que se capture a decisión de consentimento

O SDK de Segment pódese configurar para non enviar eventos ata que se chame analytics.load(). Diferir a chamada load ata que o CMP capture a decisión do usuario, para que ningún evento se dispaare pre-consentimento. Alternativamente, use o padrón de encolado analytics.ready() coa restrición de estado de consentimento nos propios manipuladores de eventos.

3. Adxuntar o payload de consentimento a cada evento

Configure a característica Consent Management para selo a cadea TC de IAB, cadea GPP, ou a súa categorización personalizada a cada evento inxerido. O selo viaxaA a través da canalización de Segment e está dispoñible para filtros de destino.

4. Escribir filtros de destino para execución a nivel de categoría

Para cada destino, escriba un filtro que comprobe o payload de consentimento contra a categoría que ese destino require. Se o usuario aceptou marketing pero rexeitou analítica, os destinos de categoría marketing reciben o evento e os destinos de categoría analítica son silenciosamente descartados. A lóxica do filtro tipicamente le desde event.context.consent.categoryPreferences ou o camiño equivalente no esquema de payload de consentimento.

5. Propagar revogacións

Cando o usuario revoga o consentimento, dúas cousas teñen que suceder: o SDK deixa de enviar novos eventos baixo as categorías revogadas (manexado polo toggle de integracións a nivel de fonte), e o perfil de usuario existente nos destinos posteriores necesita ser actualizado ou eliminado. A Privacy API de Segment soporta tanto solicitudes de eliminación como bandeiras de supresión; configure o CMP para chamar ao punto final de Privacy API apropiado sobre revogación.

Trampos Comúns

Catro erros de integración contan para a maioría das achegaduras de auditoría nos desplegues de Segment.

Tratar Segment como un único rastreador

O defecto máis común: restrinxir Segment baixo unha única categoría (normalmente analítica) e asumir que satisfai todo aguas abaixo. Non o fai. Se Facebook Pixel está habilitado como destino, o evento reenviado a Facebook require consentimento de categoría marketing, non analítica. A categorización por destino é obrigatoria.

Esquecerse do destino do almacén

Moitos equipos habilitan Snowflake ou BigQuery como destino de Segment e tratan o almacén como exento porque "é infraestrutura interna". O almacén en si pode ser interno, pero o procesamento posterior — taboleiros BI, modelaxe de similitude, segmentación de clientes — alimenta funcións de marketing e analítica. A categorización de consentimento do almacén debería reflectir o uso máis permisivo cara ao que os datos do almacén eventualmente fluír.

Fontes de lado do servidor sen contexto de consentimento

Segment soporta fontes de lado do servidor (o seu backend chamando Segment directamente). Os eventos destas fontes non herdan automaticamente o estado de consentimento de lado do navegador. A aplicación debe buscar o estado de consentimento do usuario no momento de emisión do evento e adxuntalo á chamada. Sen isto, os eventos de lado do servidor bypasean o CMP completamente.

Ignorar a fusión de identidade entre fontes

A resolución de identidade de Segment fusiona perfís anónimos e identificados, e pode facelo entre fontes web, móbiles e de lado do servidor. Se o estado de consentimento diferenza entre estas superficies, o perfil fusionado herda a interpretación máis permisiva por defecto. Configure a resolución de identidade para usar o estado de consentimento máis restrictivo a través de identidades fusionadas, non a máis permisiva.

Lista de verificación de auditoría

Seis preguntas concretas a responder para calquera despregue de Segment tocando tráfico de EU, UK, ou California.

• ¿Está documentada a categorización de destinos? Para cada destino habilitado, ¿existe un rexistro escrito de que categoría de CMP o controla?
• ¿Agarda o SDK ao consentimento? Abra a páxina nunha xanela privada e confirme que ninguén analytics.track chama se dispara a api.segment.io antes de que o banner sexa aceptado.
• ¿Están os payloads de consentimento selo en cada evento? Inspeccione unha moestra de eventos inxeridos no depurador de Segment e confirme que o payload de consentimento está presente e completo.
• ¿Honran os filtros de destino as categorías? Confirme que desactivar unha categoría no CMP resulta en eventos non sendo reenviados a destinos nesa categoría.
• ¿Levan as fontes de lado do servidor consentimento? Confirme que as chamadas de lado do servidor buscan e adxuntan o estado de consentimento actual do usuario no momento de emisión.
• ¿Dispárase a Privacy API na revogación? Confirme que as revogacións desencadeadas por CMP chaman á API de supresión ou eliminación de Segment, non só a desactivación local do SDK.

Onde Segment encaixa nunha pila de Consentimento en Primeiro Lugar

Os CDPs ocupan a posición máis apalancada na arquitectura de privacidade: unha única decisión no banner de CMP ten que propagarse a ducias de destinos posteriores, cada un coa súa propia postura legal. A arquitectura correcta trata o CMP como a fonte de verdade para as preferencias de categoría do usuario, adxunta esa verdade a cada evento que Segment inxire, e usa os primitivos de filtro de destino de Segment para executar a restrición a nivel de categoría na capa de enrutamento en lugar de en cada destino individual. Feito correctamente, o traballo de enxeñería escala linealmente coa conta de destino — engadir un novo destino é unha decisión de categorización e unha regra de filtro, non unha integración nova. Feito incorrectamente, o CDP convértese nun multiplicador de privacidade, reenviando eventos que violan consentimento a un longo final de asociados máis rápido do que calquera auditoría manual pode alcanzar.