Piotr Maćkówka
Wszystkie wpisy

4 czerwca 2026

Własne testy A/B w GTM i Firebase — bez dedykowanego narzędzia

Dedykowane platformy do testów A/B potrafią kosztować więcej niż cała reszta stacku analitycznego. A jeśli masz porządny tracking, solidny test zrobisz samodzielnie — w Google Tag Managerze na webie i w Firebase na mobile — za darmo i pod pełną kontrolą. Jeden warunek: test jest tylko tak wiarygodny, jak dane pod nim (o tym pisałem w architekturze danych pod AI — tu obowiązuje to samo).

Uwaga: część feature’ów, które realnie testowałem, była na tyle specyficzna dla jednego biznesu, że celowo je tu uogólniam. Liczy się metoda, nie konkretny przycisk.

Sedno: first-party cookie trzyma wariant, GTM nim zarządza, GA4 go raportuje. Tag custom-HTML przy wejściu losuje wariant, zapisuje go w ciasteczku i wysyła do dataLayer:

// GTM custom HTML — przydział wariantu i zapis do first-party cookie
(function () {
  var test = 'ab_cta';                          // nazwa testu
  if (getCookie(test)) return;                  // user ma już wariant — nie losuj ponownie
  var variant = Math.random() < 0.5 ? 'v0' : 'v1';
  setCookie(test, variant, 30);                 // ciasteczko na 30 dni
  dataLayer.push({
    event: 'ab_assign',
    ab_test: test,
    ab_variant: variant
  });
})();

Trzy rzeczy, które robią z tego system, a nie hak:

  • Jeden wspólny tag odpala się na evencie ab_assign i obsługuje wszystkie testy — każdy test pcha ten sam event z własną nazwą i wariantem. Nie mnożysz tagów.
  • Wariant jako wymiar niestandardowy (na poziomie sesji) w GA4 — bez tego nie posegmentujesz metryk.
  • Przydzielaj w punkcie ekspozycji. Losuj tam, gdzie user staje się uprawniony do testu — dla zmiany widocznej tylko w koszyku rób to na wejściu do koszyka. Przydzielanie na każdej stronie nie psuje proporcji 50/50 wśród wchodzących do koszyka (losowanie jest niezależne od tego, czy ktoś tam dotrze), ale rozmywa wynik: wrzucasz do analizy tłum userów, którzy zmiany nigdy nie zobaczyli, i tracisz moc statystyczną. Wcześniejszy przydział ma sens tylko wtedy, gdy wariant musi być gotowy przed daną stroną (zmiana widoczna już wcześniej albo ryzyko „mignięcia” przy decyzji na renderze) — i wtedy i tak filtruj analizę do faktycznie eksponowanych. To ta sama zasada, co activation event w Firebase.

Gdy wyłoni się zwycięzca, zmieniasz skrypt tak, by wymusić wygrany wariant u wszystkich (warunek nadpisujący ciasteczko dla pozostałych grup) i puszczasz 100% ruchu.

A/B testy w Firebase Remote Config (mobile)

Na mobile nie ma ciasteczek — jest Firebase A/B Testing na Remote Config. Konsola Firebase → A/B Testing → Create experiment → Remote config. Kilka rzeczy, które nie są oczywiste:

  • Osobny eksperyment per platforma (Android i iOS). Nazwy prefiksuj [AND] / [IOS].
  • Targeting: wybierasz aplikację i ustawiasz suwak na 100% userów (lub warunki).
  • Activation event — tu jest pułapka. To zdarzenie decyduje, kto wchodzi do testu (np. view_item dla oglądających kartę produktu). Ale activation event musi być eventem bez parametrów. Jeśli chcesz aktywować na parze event + parametr (np. tylko karty z ofertą 3P), musisz stworzyć dedykowany event (np. view_item_3p). Ta sama zasada dotyczy metryk w Goals.
  • Goals: primary metric + zawsze dorzuć purchase i przychód jako KPI kontrolne.
  • Variants mapują się na wartości klucza Remote Config. Jeśli klucza nie ma na liście — developerzy muszą najpierw wrzucić go na produkcję.

Klient czyta wartość RC i przełącza UI:

let mode = RemoteConfig.remoteConfig().configValue(forKey: "product_description_mode").stringValue
switch mode {
case "minimal":  showMinimalDescription()
case "detailed": showDetailedDescription()
default:         showClassicDescription()   // wariant kontrolny
}

Drobny, ale ważny szczegół: Firebase liczy istotność bayesowsko, nie klasycznym testem hipotez — interpretacja „prawdopodobieństwa, że wariant jest lepszy” różni się od p-value.

Analiza wyników: konwersja i przychód per wariant (GA4 → BigQuery)

Konsola GA4 wystarczy do podglądu, ale realną kontrolę daje SQL na eksporcie GA4 do BigQuery — zwłaszcza gdy chcesz policzyć konwersję i przychód dokładnie tak, jak definiujesz je w biznesie:

-- Wyniki testu A/B: użytkownicy, konwersja, przychód i ARPU per wariant
WITH assignment AS (                       -- wariant przypisany użytkownikowi
  SELECT
    user_pseudo_id,
    (SELECT value.string_value FROM UNNEST(event_params)
       WHERE key = 'ab_variant') AS variant
  FROM `projekt.analytics_XXXXXX.events_*`
  WHERE event_name = 'ab_assign'
    AND _TABLE_SUFFIX BETWEEN '20260501' AND '20260531'
),
purchases AS (                             -- transakcje i przychód
  SELECT
    user_pseudo_id,
    COUNT(*)                        AS transactions,
    SUM(ecommerce.purchase_revenue) AS revenue
  FROM `projekt.analytics_XXXXXX.events_*`
  WHERE event_name = 'purchase'
    AND _TABLE_SUFFIX BETWEEN '20260501' AND '20260531'
  GROUP BY user_pseudo_id
)
SELECT
  a.variant,
  COUNT(DISTINCT a.user_pseudo_id)                                   AS users,
  COUNT(DISTINCT p.user_pseudo_id)                                   AS buyers,
  SAFE_DIVIDE(COUNT(DISTINCT p.user_pseudo_id),
              COUNT(DISTINCT a.user_pseudo_id))                      AS conversion_rate,
  IFNULL(SUM(p.revenue), 0)                                          AS revenue,
  SAFE_DIVIDE(SUM(p.revenue), COUNT(DISTINCT a.user_pseudo_id))      AS arpu
FROM assignment a
LEFT JOIN purchases p USING (user_pseudo_id)
WHERE a.variant IS NOT NULL
GROUP BY a.variant
ORDER BY a.variant;

Masz w jednej tabeli wielkość grup, współczynnik konwersji, przychód i ARPU — czyli wszystko, czego trzeba do decyzji, którą wersję wypuścić na 100%.

Pułapki, o których łatwo zapomnieć

  • Zgody (RODO). Ciasteczko testu podlega Consent Mode — losowanie i zapis ustaw zgodnie ze stanem zgód, nie ponad nim.
  • Jeden user = jeden wariant. Ciasteczko to pamięć przydziału; nie losuj ponownie przy każdej odsłonie.
  • Firebase: bez parametrów. Activation event i metryki celu muszą być eventami bez parametrów — inaczej test nie ruszy.
  • Spójność web↔mobile. To dwa osobne mechanizmy (cookie vs Remote Config) — pilnuj, by definicja wariantu i metryki były takie same po obu stronach.

Cała reszta to dyscyplina: dobra warstwa zdarzeń pod spodem, jeden wariant na użytkownika i metryka liczona tak samo dla każdej grupy. Narzędzie jest tanie — wiarygodność bierze się z trackingu.

Powiązane wpisy