Co Segment skutečně dělá

SDK Segmentu (načteno z cdn.segment.com/analytics.js) inicializuje globální objekt analytics a identifikuje návštěvníky pomocí cookie ve vlastnictví Segmentu nazývané ajs_anonymous_id. Kód aplikace volá analytics.identify(), analytics.track(), analytics.page() a analytics.group() a SDK předává každé volání do vstupního bodu Segmentu. Odtud Segment distribuuje událost — v reálném čase nebo dávkově — do jakýchkoli povolených destinací ve zdroji: Google Analytics, Facebook Pixel, Customer.io, Iterable, Amplitude, Mixpanel, Snowflake, BigQuery a desítek dalších.

Každé předání navazující destinaci je z pohledu GDPR samostatnou aktivitou zpracování. Právní základ pro odeslání události do Google Analytics není stejný jako právní základ pro odeslání stejné události do Customer.io a není stejný jako zápis stejné události do skladu Snowflake. Banner souhlasu, který zaznamená jediné „přijímám marketing", nemůže legitimně autorizovat všechny tyto aktivity sám o sobě, pokud kategorizace destinací neodpovídá kategorizaci souhlasu.

Nativní primitivy souhlasu Segmentu

Segment za poslední dva roky výrazně investoval do primitiv správy souhlasu. Od roku 2026 platforma nabízí tři smysluplné povrchy pro vynucování souhlasu.

Consent Management (dříve Consent Stamping)

Funkce Consent Management umožňuje připojit datovou část souhlasu ke každé události, kterou Segment přijme. Datová část zaznamenává, které kategorie zpracování uživatel přijal — obvykle řetězec IAB TCF v2.3, řetězec GPP nebo vlastní kategorizaci Segmentu. Navazující destinace lze nakonfigurovat tak, aby přeposílaly nebo blokovaly na základě stavu souhlasu u každé události.

Filtry destinací se správou přístupu na základě souhlasu

Filtry destinací umožňují napsat malý výraz JavaScript nebo Lua, který se spouští u každé události před jejím přeposláním do konkrétní destinace. Filtr může zkontrolovat datovou část souhlasu a zkratovat přeposílání, pokud příslušná kategorie nebyla udělena. Toto je správná primitiva pro granulární vynucování souhlasu pro každou destinaci.

Nastavení integrations na úrovni zdroje

Pro hrubší kontrolu může objekt integrations na úrovni zdroje zcela zakázat destinace na základě každé události: analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } }). To je užitečné pro případ vše nebo nic, ale nezvládá dobře granularitu na úrovni kategorií.

Integrace CMP krok za krokem

Spolehlivá architektura spočívá v mapování rozhodnutí kategorií CMP na kategorizaci destinací Segmentu, připojení datové části souhlasu ke každé události a použití filtrů destinací k vynucování správy přístupu pro každou destinaci.

1. Kategorizujte destinace

Projděte seznam povolených destinací v pracovním prostoru Segmentu a přiřaďte každou z nich do kategorie CMP. Destinace jako Google Analytics, Mixpanel a Amplitude jsou obvykle analytické. Destinace jako Facebook Pixel, TikTok a Pinterest jsou obvykle marketingové. Destinace jako Snowflake nebo BigQuery (váš vlastní sklad) jsou obvykle nezbytné nebo funkční — ale pouze pokud je analytika zpracovávaná na nižší úrovni skladu také správně kategorizována. Zdokumentujte toto mapování někde, kde je možné jej zkontrolovat; obhajoba při auditu na něm závisí.

2. Odložte inicializaci SDK, dokud není zaznamenáno rozhodnutí o souhlasu

SDK Segmentu lze nakonfigurovat tak, aby neodesílal události, dokud není zavolána funkce analytics.load(). Odložte volání načtení, dokud CMP nezaznamená rozhodnutí uživatele, aby před souhlasem nevznikaly žádné události. Alternativně použijte vzor řazení do fronty analytics.ready() se správou přístupu na základě stavu souhlasu přímo v obslužných rutinách událostí.

3. Připojte datovou část souhlasu ke každé události

Nakonfigurujte funkci Consent Management pro orazítkování řetězce IAB TC, řetězce GPP nebo vaší vlastní kategorizace na každou přijatou událost. Razítko putuje s událostí prostřednictvím pipeline Segmentu a je dostupné pro filtry destinací.

4. Napište filtry destinací pro vynucování na úrovni kategorií

Pro každou destinaci napište filtr, který kontroluje datovou část souhlasu oproti kategorii, kterou tato destinace vyžaduje. Pokud uživatel přijal marketing, ale odmítl analytiku, destinace kategorie marketing obdrží událost a destinace kategorie analytika jsou tiše zahozeny. Logika filtru obvykle čte z event.context.consent.categoryPreferences nebo z ekvivalentní cesty ve schématu datové části souhlasu.

5. Šiřte odvolání

Když uživatel odvolá souhlas, musí dojít ke dvěma věcem: SDK přestane odesílat nové události v odvolaných kategoriích (řízeno přepínačem integrations na úrovni zdroje) a stávající profil uživatele v navazujících destinacích musí být aktualizován nebo odstraněn. Privacy API Segmentu podporuje jak žádosti o smazání, tak příznaky potlačení; nakonfigurujte CMP pro volání příslušného koncového bodu Privacy API při odvolání.

Běžné nástrahy

Čtyři integrační chyby vysvětlují většinu auditních nálezů při nasazeních Segmentu.

Zacházení se Segmentem jako s jediným sledovačem

Nejběžnější nedostatek: omezení Segmentu pod jedinou kategorii (obvykle analytika) a předpoklad, že to pokrývá vše na nižší úrovni. Nepokrývá. Pokud je Facebook Pixel povolen jako destinace, událost přeposlaná na Facebook vyžaduje souhlas kategorie marketing, nikoli analytika. Kategorizace pro každou destinaci je povinná.

Zapomenutí na destinaci skladu

Mnoho týmů povolí Snowflake nebo BigQuery jako destinaci Segmentu a považuje sklad za osvobozený, protože „jde o interní infrastrukturu". Samotný sklad může být interní, ale následné zpracování — BI dashboardy, modelování podobných publik, segmentace zákazníků — slouží marketingovým a analytickým funkcím. Kategorizace souhlasu skladu by měla odrážet nejpermisivnější použití, do kterého data skladu nakonec proudí.

Zdroje na straně serveru bez kontextu souhlasu

Segment podporuje zdroje na straně serveru (váš backend volá Segment přímo). Události z těchto zdrojů automaticky nedědí stav souhlasu na straně prohlížeče. Aplikace musí vyhledat stav souhlasu uživatele v okamžiku emisí události a připojit jej k volání. Bez tohoto opatření události na straně serveru zcela obcházejí CMP.

Ignorování křížového slučování identit

Rozlišení identit Segmentu slučuje anonymní a identifikované profily a může tak činit napříč webovými, mobilními a serverovými zdroji. Pokud se stav souhlasu mezi těmito povrchy liší, sloučený profil ve výchozím nastavení zdědí nejpermisivnější interpretaci. Nakonfigurujte rozlišení identit tak, aby používalo nejrestriktivnější stav souhlasu napříč sloučenými identitami, nikoli nejpermisivnější.

Kontrolní seznam auditu

Šest konkrétních otázek, na které je třeba odpovědět pro jakékoli nasazení Segmentu dotýkající se provozu EU, UK nebo Kalifornie.

• Je kategorizace destinací zdokumentována? Pro každou povolenou destinaci existuje písemný záznam, která kategorie CMP ji řídí?
• Čeká SDK na souhlas? Otevřete stránku v soukromém okně a potvrďte, že se žádná volání analytics.track neodesílají na api.segment.io před přijetím banneru.
• Jsou datové části souhlasu orazítkovány na každé události? Zkontrolujte vzorek přijatých událostí v debuggeru Segmentu a potvrďte, že datová část souhlasu je přítomna a úplná.
• Respektují filtry destinací kategorie? Potvrďte, že zakázání kategorie v CMP vede k tomu, že události nejsou přeposílány do destinací v této kategorii.
• Nesou zdroje na straně serveru souhlas? Potvrďte, že volání na straně serveru vyhledávají a připojují aktuální stav souhlasu uživatele v okamžiku emise.
• Spouští se Privacy API při odvolání? Potvrďte, že odvolání iniciovaná CMP volají API pro potlačení nebo smazání v Segmentu, nikoli pouze místní opt-out SDK.

Kde Segment zapadá do zásobníku s prioritou souhlasu

CDP zaujímají nejvýkonnější pozici v architektuře ochrany soukromí: jediné rozhodnutí v banneru CMP musí být šířeno do desítek navazujících destinací, přičemž každá má svou vlastní právní pozici. Správná architektura považuje CMP za zdroj pravdy pro kategoriální preference uživatele, připojuje tuto pravdu ke každé události, kterou Segment přijímá, a využívá primitiva filtrů destinací Segmentu k vynucování správy přístupu na úrovni kategorií na vrstvě směrování, nikoli u každé jednotlivé destinace. Provedeno správně, inženýrská práce se škáluje lineárně s počtem destinací — přidání nové destinace je rozhodnutí o kategorizaci a pravidlo filtru, nikoli nová integrace. Provedeno nesprávně, CDP se stává multiplikátorem ochrany soukromí a přeposílá události porušující souhlas do dlouhé řady partnerů rychleji, než jakýkoli ruční audit stačí dohnat.