Шта Segment заправо ради

Segment SDK (учитан са cdn.segment.com/analytics.js) иницијализује глобални analytics објекат и идентификује посетиоце колачићем у власништву Segment-а под именом ajs_anonymous_id. Апликациони код позива analytics.identify(), analytics.track(), analytics.page() и analytics.group(), а SDK сваки позив прослеђује Segment-овом крајњем тачку за унос. Одатле Segment разгранава догађај — у реалном времену или путем серије — ка свим одредиштима омогућеним на извору: Google Analytics, Facebook Pixel, Customer.io, Iterable, Amplitude, Mixpanel, Snowflake, BigQuery и десетинама других.

Свако прослеђивање ка нижем одредишту представља засебну активност обраде са становишта GDPR. Правна основа за слање догађаја ка Google Analytics није иста као правна основа за слање истог догађаја ка Customer.io, нити иста као уписивање истог догађаја у Snowflake складиште. Банер сагласности који бележи само „Прихватам маркетинг" не може законито да ауторизује све ово сам по себи осим ако категоризација одредишта одговара категоризацији сагласности.

Изворни примитиви сагласности у Segment-у

Segment је снажно улагао у примитиве управљања сагласношћу у протекле две године. Од 2026. платформа излаже три значајне површине за примену сагласности.

Consent Management (раније Consent Stamping)

Функција Consent Management омогућава прикачивање садржаја сагласности уз сваки догађај који Segment уноси. Садржај бележи које категорије обраде је корисник прихватио — типично IAB TCF v2.3 стринг, GPP стринг или прилагођена Segment категоризација. Нижа одредишта могу бити конфигурисана да прослеђују или блокирају на основу стања сагласности сваког догађаја.

Филтри одредишта са контролом сагласности

Филтри одредишта омогућавају писање малог JavaScript или Lua израза који се извршава за сваки догађај пре прослеђивања одређеном одредишту. Филтар може прегледати садржај сагласности и прекинути прослеђивање ако релевантна категорија није одобрена. Ово је прави примитив за детаљно, по-одредишно спровођење сагласности.

Подешавање integrations на нивоу извора

За грубљу контролу, објекат integrations на нивоу извора може онемогућити одредишта у потпуности по догађају: analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } }). Ово је корисно за случај све-или-ништа, али не обрађује добро гранулацију на нивоу категорије.

Корак по корак: интеграција CMP

Поуздана архитектура подразумева мапирање одлука о категоријама CMP на категоризацију одредишта у Segment-у, прикачивање садржаја сагласности на сваки догађај и употребу филтара одредишта за спровођење контроле по одредишту.

1. Категоризовање одредишта

Прегледајте листу омогућених одредишта у Segment радном простору и сваком доделите CMP категорију. Одредишта попут Google Analytics, Mixpanel и Amplitude типично спадају у аналитику. Одредишта попут Facebook Pixel, TikTok и Pinterest типично спадају у маркетинг. Одредишта попут Snowflake или BigQuery (сопствено складиште) типично су нужна или функционална — али само ако је аналитика обрађена после складишта такође исправно категорисана. Документујте ово мапирање на прегледном месту; одбрана ревизије почива на томе.

2. Одлагање иницијализације SDK до хватања одлуке о сагласности

Segment SDK може бити конфигурисан да не шаље догађаје све до позива analytics.load(). Одложите позив учитавања до тренутка када CMP прикупи корисникову одлуку, тако да ниједан догађај не буде емитован пре сагласности. Алтернативно, употребите образац редовања analytics.ready() са контролом стања сагласности у самим руковаоцима догађаја.

3. Прикачивање садржаја сагласности на сваки догађај

Конфигуришите функцију Consent Management да утискује IAB TC стринг, GPP стринг или прилагођену категоризацију на сваки унети догађај. Утисак путује са догађајем кроз Segment цевовод и доступан је филтрима одредишта.

4. Писање филтара одредишта за примену на нивоу категорије

За свако одредиште напишите филтар који проверава садржај сагласности у односу на категорију коју то одредиште захтева. Ако је корисник прихватио маркетинг, али одбио аналитику, одредишта категорије маркетинг примају догађај, а одредишта категорије аналитике се тихо одбацују. Логика филтра типично чита из event.context.consent.categoryPreferences или еквивалентне путање у шеми садржаја сагласности.

5. Прослеђивање опозива

Када корисник опозове сагласност, потребно је да се деси двоје: SDK престаје да шаље нове догађаје под опозваним категоријама (обрађено прекидачем integrations на нивоу извора), а постојећи кориснички профил у нижим одредиштима мора бити ажуриран или избрисан. Privacy API Segment-а подржава и захтеве за брисање и заставице за потискивање; конфигуришите CMP да позива одговарајући Privacy API крајњу тачку приликом опозива.

Уобичајене замке

Четири грешке при интеграцији чине већину налаза ревизије у Segment постројењима.

Третирање Segment-а као јединствени трекер

Најчешћи пропуст: постављање Segment-а под јединствену категорију (обично аналитику) и претпоставка да то задовољава све ниже. Не задовољава. Ако је Facebook Pixel омогућен као одредиште, догађај прослеђен Facebook-у захтева сагласност категорије маркетинг, а не аналитике. Категоризација по одредишту је обавезна.

Заборављање одредишта складишта

Многи тимови омогућавају Snowflake или BigQuery као Segment одредиште и третирају складиште као изузето јер „то је интерна инфраструктура". Само складиште може бити интерно, али накнадна обрада — BI контролне табле, lookalike моделовање, сегментација купаца — напаја маркетиншке и аналитичке функције. Категоризација сагласности складишта треба да одражава најшире коришћење у које подаци складишта на крају упадају.

Извори на страни сервера без контекста сагласности

Segment подржава изворе на страни сервера (ваш backend директно позива Segment). Догађаји из ових извора не наслеђују аутоматски стање сагласности са стране претраживача. Апликација мора потражити стање сагласности корисника у тренутку емисије догађаја и прикачити га уз позив. Без тога, догађаји на страни сервера у потпуности заобилазе CMP.

Занемаривање спајања идентитета из различитих извора

Сегментово решавање идентитета спаја анонимне и идентификоване профиле, и то може чинити преко веб, мобилних и серверских извора. Ако се стање сагласности разликује међу овим површинама, спојени профил по подразумеваном наслеђује најшире тумачење. Конфигуришите решавање идентитета да користи најрестриктивније стање сагласности међу спојеним идентитетима, а не најшире.

Контролна листа ревизије

Шест конкретних питања на која треба одговорити за свако Segment постројење које обухвата EU, UK или калифорнијски саобраћај.

• Да ли је категоризација одредишта документована? За свако омогућено одредиште, постоји ли писани запис о томе која CMP категорија га контролише?
• Да ли SDK чека на сагласност? Отворите страницу у приватном прозору и потврдите да ниједан позив analytics.track не иде ка api.segment.io пре прихватања банера.
• Да ли се садржаји сагласности утискују на сваки догађај? Прегледајте узорак унетих догађаја у Segment дебагеру и потврдите да је садржај сагласности присутан и потпун.
• Да ли филтри одредишта поштују категорије? Потврдите да онемогућавање категорије у CMP резултира тиме да се догађаји не прослеђују одредиштима у тој категорији.
• Да ли извори на страни сервера носе сагласност? Потврдите да позиви на страни сервера проналазе и прикачују тренутно стање сагласности корисника у тренутку емисије.
• Да ли Privacy API активира при опозиву? Потврдите да опозиви иницирани путем CMP позивају Segment API за потискивање или брисање, а не само локалну SDK одјаву.

Где Segment стаје у стек заснован на сагласности

CDP-ови заузимају највреднију позицију у архитектури приватности: јединствена одлука на CMP банеру мора да се прошири на десетине нижих одредишта, свако са сопственим правним ставом. Исправна архитектура третира CMP као извор истине о корисниковим преференцама категорија, прикачује ту истину на сваки догађај који Segment уноси и користи Segment-ове примитиве филтера одредишта за спровођење контроле на нивоу категорије у слоју рутирања, а не на сваком појединачном одредишту. Урађено исправно, инжењерски рад расте линеарно са бројем одредишта — додавање новог одредишта је одлука о категоризацији и правило филтра, а не нова интеграција. Урађено погрешно, CDP постаје мултипликатор приватности, прослеђујући догађаје са кршењем сагласности дугачком репу партнера брже него што икаква ручна ревизија може да достигне.