Storefront-ID multi-domain analitika — ahogy a 13 marketing site egyetlen tenant alatt mér

Klasszikus dilemma: futtatsz 13 marketing-domaint (mindegyik más-más szubmárka, célközönség, kampány), és el kell döntened, hogyan mérsz. A „triviális” válasz: 13 darab GA4-property + 13 GTM-konténer. Mi nem így csináljuk — és érdemes elmondani, miért nem.

Az anti-pattern: 13 különálló analytics-property

Miért tűnik jónak elsőre?

• Mindegyik site külön kezelhető, külön user-list, külön goal-set.
• Marketing-csapatok per-site dashboard-okat tudnak építeni.
• A „kis Acme”-domain nem keveredik a „nagy nortinia.com”-mal.

Miért nem jó valójában?

• Cross-domain user-journey nem mérhető. A vásárló a kampány-landingon belép (acme-landing.hu), átkattint a fő márkára (nortinia.com), ott vásárol. GA4-ben két különálló session lesz, a konverzió attribúciója szétesik.
• 13× karbantartás. Egy új event (pl. „cart-line-clicked-thumbnail”) bevezetése 13 helyen, 13 reggeli sync-meeting.
• Aggregátum-jelentés nincs. A CEO „mi az össz-konverzió az ökoszisztémában?” kérdésre csak Excelben tudsz válaszolni.
• Tenant-szintű AI-modellek (recommender, predictor) éhen halnak. Nincs elég sample egy-egy site-on, és a 13 sample-pool nem fésülhető.

A nortinia-megközelítés: X-Storefront-Domain header + egyetlen pool

Minden ökoszisztéma-site ugyanazt a backend-et hívja, mindegyik kéréshez beszúr egy X-Storefront-Domain: <host> headert. Az analytics-ingest egyetlen storage-ba ír, ahol a storefront_id egy dimenzió.

GET /api/v1/public/products HTTP/1.1
Host: api.nortinia.com
X-Storefront-Domain: acme-landing.hu

A dashboard ezután:

• Default view — minden site együtt (CEO-dashboard, ökoszisztéma-szintű KPI-k)
• Per-storefront filter — egy klikk a sidebar-ban, a marketing-csapat a saját site-jára szűr
• Cross-domain funnel — storefront_id IN (acme-landing.hu, nortinia.com) → a valódi journey-t látja

Mit nyerünk konkrétan

Egy 2026 Q1 audit a saját ökoszisztémánkon:

• Attribúciós lift: a cross-domain journey-k 23%-án kívülről érkezett a vásárló, de a fő domainen konvertált. Korábban a fő domain első-érintkezésnek látszott; valójában az acme-landing volt az igazi acquisition-csatorna. Az ott elköltött 4,200 EUR/hó ad-budget átsúlyozódott.
• Új event bevezetés: „bundle-suggestion-shown” event átfutási ideje 13 → 1 sprint. Egyszer kell implementálni a shared package-ben.
• AI recommender betanítási idő: 6 hét → 9 nap, mert az aggregate-data minden site-tól érkezik egy pool-ba.

A trade-off-ok, amit őszintén el kell mondani

Nem ingyen ebéd:

1. Tenant-separation a backendben kemény — tenant_id minden lekérdezésen, RLS bekapcsolva, audit-log a per-storefront filterek használatára. Egy elfelejtett filter → kereszt-szivárgás.
2. GDPR-consent storefront-szerinti tárolás — az acme-landing.hu-n adott hozzájárulás NEM érvényes a nortinia.com-on. Külön cookie-banner, külön consent-record, ami (user_hash, storefront_id, consent_type) kulccsal tárolódik.
3. Marketing-csapatok küszöbe magasabb — a per-site nézethez először tanítani kell a csapatokat a szűrésre. Default-ban nem az ő site-juk látszik; ez kezdetben frusztráló.

Mikor NE csináld így

Ha a 13 site:

• különálló jogi entitás (B2B partnerei, nem ökoszisztémád),
• külön GDPR data-controller,
• ahol soha nem lesz cross-domain user-journey,

…akkor a 13 különálló property nemcsak elfogadható, hanem kötelező. A nortinia.com / netorigo.com / 11 testvér site egy ökoszisztéma, közös tenant, közös data-controller — itt a single-pool a természetes válasz.

A tanulság

A „13 site → 13 analytics” triviálisnak tűnik, de elveszíti azt, ami a 13-as számon múlik: a journey-ket. Ha a vásárlóid keresztezik a domaint, mérj storefront_id dimenzióval egyetlen pool-ban — és tervezd be a separation-kötelességeket a backenden és a consenten.