Vissza a Journal-hoz
netorigohu

Multi-storefront analitika — 13 site, egy tenant, egy tabla

Egy analytics_events tabla, egy X-Storefront-Domain header, 13 storefront per-domain konverzio egy SQL GROUP BY-jal — nem 13 kulon Plausible-instance.

Tizenharom storefront ugyanazon a Netorigo Kft. tenanton. A vegyes katalogus, a kozos checkout, a kozos finance — mindennek megvan az ara: hogyan tudjuk a per-domain konverziot kulon-kulon merni anelkul, hogy 13 kulon Plausible-instancet kelljen futtatnunk. A valasz a X-Storefront-Domain header es egy analytics_events tabla, amibol minden kerdes megvalaszolhato.

A problema mas SaaS-okban

Egy klasszikus single-tenant analitikai megoldas (Plausible, Fathom, GA4) per-property mer. Ha 13 storefronted van, 13 property-t veszel, 13 dashboardot allitasz be, es ket honap mulva mar nem nezi senki. Az osszehasonlitas — „Nortinia hogyan teljesit Mediaorigo-hoz kepest?” — egy CSV-export utan harom Excel cellaban folytatodik.

Nekunk mas megoldas kellett: egy adattabla, sok dimenzio.

A header mint dimenzio

Minden storefront tudja a sajat domainjet (a Next.js host headerbol vagy egy STOREFRONT_DOMAIN env varbol). Minden analytics-event egy X-Storefront-Domain: nortinia.com headert kuld a BE-re. A BE controller ezt kiolvassa, validalja (whitelist: tenant 13 elismert domain-je), es a analytics_events tablaba mentett rekord storefront_domain oszlopaba teszi.

Most mar egyetlen SQL query elinteziz mindent:

SELECT
  storefront_domain,
  COUNT(*) FILTER (WHERE event_type = 'page_view') AS views,
  COUNT(*) FILTER (WHERE event_type = 'add_to_cart') AS adds,
  COUNT(*) FILTER (WHERE event_type = 'order_completed') AS orders
FROM analytics_events
WHERE tenant_id = 'netorigo-kft'
  AND created_at >= NOW() - INTERVAL '30 days'
GROUP BY storefront_domain
ORDER BY orders DESC;

Egyetlen GROUP BY-jal megvan a 13-soros osszehasonlito tabla. A kovetkezo lekerdezessel mar (storefront_domain, traffic_source)-ra bonthatjuk a koverziot — ami egy klasszikus SaaS-analitikaban harom kulon export-ot igenyelne.

Mi van a tablaban

A analytics_events osszesen 24 oszlop, de a leglenyegesebbek:

  • id (uuid)
  • tenant_id (mindig kotelezo)
  • storefront_domain (a kulcs-dimenzio)
  • session_id (anonim cookie-ID)
  • event_type (page_view, add_to_cart, checkout_start, order_completed, rfq_submit, voice_session_start, stb.)
  • event_data (JSONB: termek-SKU, ar, refer-URL, stb.)
  • user_id (opcionalis — csak ha bejelentkezett)
  • created_at
  • country_code (Cloudflare header-bol)
  • device_type (mobile/tablet/desktop)
  • path (a vasarlo melyik URL-en volt)

13 storefront atlagosan napi 8000 eventet generál (negative skala — kis ceg + B2B fokusz), tehat ev/3M rekord. PostgreSQL ezt simán bírja BRIN index-szel a created_at-en + BTREE a (tenant_id, storefront_domain, event_type)-on. Particionalas csak 50M rekord folott valna szuksegesse — meg sok ev.

Mit kerdez tipikusan a CMO

A marketing csapatunk vagy a tenant ugyfel-CMO-i tipikusan ezeket a kerdeseket teszik fel, es mindegyik egyetlen SQL-bol (vagy egy egyseges dashboardon) megvalaszolhato:

  • „Melyik storefronton volt a legjobb a fekete-pentek konverzioja?”WHERE created_at BETWEEN '2025-11-28' AND '2025-12-01', GROUP BY storefront_domain, megnezed az orders/views aranyt.
  • „A nortinia.com mobil vs. desktop konverzio?”WHERE storefront_domain = 'nortinia.com', GROUP BY device_type.
  • „Az osszes tenant-szintu konverzio az utolso 30 napban?”WHERE tenant_id = 'netorigo-kft' cross-domain.
  • „Melyik storefront kapja a legtobb voice-session-t?”WHERE event_type = 'voice_session_start', GROUP BY storefront_domain.
  • „Melyik termek vezet egyszerre 3 vagy tobb storefronton?”JOIN products, GROUP BY product_id HAVING COUNT(DISTINCT storefront_domain) >= 3.

A kulonbseg a Plausible-tol

A Plausible vagy GA4 elony egy darab dashboard, ami megnyilik 5 mp alatt. A mi modellunk hatrányt eppen az, hogy nincs out-of-the-box pretty dashboard — egy belso analytics-eszkoz (Metabase, vagy a Netorigo Admin „Reports” tab) hozza fel a vizualizaciot. Az elony viszont: barmilyen kerdes megvalaszolhato 5 perces SQL-lel, nem csak az, amit a SaaS-vendor pre-built-ben mer.

Vegszo

13 storefront + egy header + egy tabla + egy GROUP BY = a multi-storefront analitika osszes problemaja megoldva. Az X-Storefront-Domain egy 26 betus header, de a teljes ertekteremtest is hozza maga utan az osszes tenanthoz aki belep az okoszisztemanba.