BigQuery. Deduplikacja purchase. Jeden wiersz na transaction_id w eksporcie GA4.

Na czym to polega w sklepie

CRM pokazuje 412 zamówień, raport SQL z surowego GA4 - 487. Skąd różnica? Ten sam transaction_id może pojawić się kilka razy (odświeżenie strony podziękowania, server + client). ROW_NUMBER() OVER (PARTITION BY transaction_id …) zostawia jeden wiersz na zamówienie.

Przykład ze sklepu internetowego

Marketplace po wdrożeniu server-side GTM buduje tabelę dziennych zamówień - bierze ostatni hit purchase per transaction_id przed joinem z kosztami Ads:

WITH ranked AS (
  SELECT
    event_date,
    transaction_id,
    ecommerce.purchase_revenue AS revenue,
    ROW_NUMBER() OVER (
      PARTITION BY transaction_id
      ORDER BY event_timestamp DESC
    ) AS rn
  FROM `project.analytics.events_*`
  WHERE event_name = 'purchase'
    AND _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
    AND transaction_id IS NOT NULL
)
SELECT event_date, COUNT(*) AS orders, SUM(revenue) AS revenue
FROM ranked
WHERE rn = 1
GROUP BY event_date;

Co zrobić po stronie biznesu

• Ustal z zespołem Ads jedną liczbę konwersji opartą na deduplikowanym eksporcie - koniec sporów o ROAS.
• Wygeneruj listę rn > 1 do audytu tagu purchase - widać, które transakcje się dublują.
• Gdy duplikaty mają różny revenue, wybierz regułę (ostatni timestamp vs MAX) i zapisz ją w runbooku raportowym.

W skrócie

Dedup w SQL to obowiązek przed każdym raportem ROAS w BigQuery. Naprawa tagu w GTM zmniejsza problem u źródła, ale warstwa SQL nadal chroni KPI przed zawyżeniem.