Import marží do reklamních systémů

Co reálně posílá většina e-shopů jako hodnotu konverze

Standardní nasazení: e-shop pošle do Google Ads při konverzi hodnotu rovnou tržbě dokončené objednávky. Stejné číslo jde do Meta pixelu nebo Conversions API. Automatické nabídky (Target ROAS, Maximize Conversion Value) se učí na tom, co dostanou. Pošlete tržbu, optimalizují na tržbu.

Alternativa potřebuje reálné nákupní ceny po SKU v okamžiku nákupu. To není analytický problém. To je datový.

Proč tržba není ideální signál

Dvě objednávky po 1 000 Kč vypadají v účtu stejně. Z jedné může zbýt 50 Kč marže, z druhé 400 Kč. Rozdíl je v mixu produktů a v marži po řádcích. Když do reklamních systémů posíláte jen tržbu, algoritmus ten rozdíl nevidí a nemá podle čeho preferovat ziskovější košíky.

Import marže ale pomůže jen tehdy, když máte v pořádku data i měření. Jinak optimalizujete na signál, který vám stejně neříká pravdu o zisku.

Co dává smysl a co ne

Import marže má smysl jen když data i měření drží pohromadě. Jinak optimalizujete na neúplný signál, ať už pošlete tržbu nebo marži.

• Marže je napříč sortimentem stejná. Stačí vám optimalizace na tržbu, případně segmentace produktů v Google Ads nebo import akvizice a retence.
• Nemáte aktuální nákupní ceny po SKU a prodejní cenu v okamžiku nákupu, jen marži přepočtenou jednou za kvartál.
• Nesedí párování produktů mezi e-shopem, ERP nebo skladem a feedem.
• Roztříštěná nebo nekvalitní data o maržích: rozštěpené zdroje, tabulky po dodavatelích a značkách, chybějící údaje. Nejdřív sjednoťte do jednoho zdroje, pak teprve marži v konverzi.
• Máte špatně nasazené měření: cookie lišta nebo souhlas nefungují, konverze se nespolehlivě posílají do Google Ads a Meta.

• Marže se mezi produkty nebo kategoriemi výrazně liší.
• Máte aktuální nákupní ceny po SKU a prodejní cenu v okamžiku nákupu.
• Prodejní i nákupní strana počítají stejně. Pokud nemáte důvod posílat do systémů ceny s DPH, počítejte marži bez DPH i v ERP.
• Párování produktů mezi e-shopem, ERP nebo skladem a feedem sedí.
• Marži čtete z jednoho datového zdroje, typicky ERP nebo sklad plus e-shop.
• Máte kvalitně nasazené měření: cookie lišta a souhlas fungují, konverze se spolehlivě posílají do Google Ads a Meta.

Za mě bez zelených bodů projekt nerozjíždějte.

Koeficient pro zachování hodnoty konverze

Když do účtu pošlete čistou marži, součty konverzních hodnot spadnou úměrně průměrné marži. Při průměru 30 % spadnou na zhruba třetinu. Automatické nabídky zvyklé na vyšší čísla začnou kolísat, doručování padne, učení se rozsype.

Řešení: marži vynásobte koeficientem rovným převrácené hodnotě průměrné marže. Při průměru 30 % je to 1 ÷ 0,3, tedy zhruba 3,33. V praxi zaokrouhluji nahoru na 3,4 nebo 3,5, aby koeficient držel mírně vyšší bid.

Co z toho plyne:

• celkový součet hodnot konverzí zůstane na podobné úrovni jako dřív,
• váha mezi objednávkami se přerozdělí: ziskové dostanou vyšší, neziskové nižší,
• systém nezačíná učení od nuly na úplně jiných číslech.

Nasazení v Google Ads

Mám odzkoušené, že novou konverzi s hodnotou z marže necháte nejdřív jako sekundární a na primární ji přepnete až po ověření dat. Když to porušíte, rozhodíte si účet.

Novou hodnotu z marže ne nasazujte hned jako primární a nepřepisujte ji do stávající primární konverze. Automatické nabídky ztratí historickou distribuci, na které se učily. Restart učení znamená 4–8 týdnů nestability podle objemu konverzí. Před spuštěním ověřte v nastavení, že se nová konverze sama nepřepne jinam: při migracích se nám to už párkrát stalo a propad výkonu trval dlouho.

Postup, který držím:

1. Založit novou konverzi s hodnotou z marže a nechat ji jako sekundární.
2. Nechat běžet minimálně 30 dní, ideálně 60. Kontrolovat shodu hodnot se skladem dat a ERP. Žádné výpadky událostí, žádné chybějící položky.
3. Teprve potom přepnout primární cíl optimalizace na novou konverzi. Tržbu nechat sekundárně ke kontrole.

Nemůžete-li založit novou konverzi a musíte měnit hodnotu u existující, koeficient z předchozí sekce je jediná pojistka před pádem výkonu. Bez paralelního měření ale letíte naslepo. Počítejte s tím jen jako s nouzovou variantou.

Nasazení v Meta

Meta je na změny měření citlivější než Google. Než cokoliv pustíte naostro, otestujte to na menším projektu nebo doméně. Experimentální měření netahajte rovnou na pixel, kde vám stojí hlavní obrat.

Dvě cesty podle stavu pixelu:

• Nový paralelní pixel jen pro optimalizaci na marži. Nerozhodíte historii původního pixelu ani publika z něj.
• Koeficient na stávajícím pixelu, kdy se hodnota nákupu přepíše na marži vynásobenou koeficientem.

I u druhé cesty si založte vedle ní druhý pixel, chvíli porovnejte hodnoty a teprve pak přepínejte primární optimalizaci. Změna měření na pixelu s lookalike publiky a dlouhou historií je drahá chyba, když se ukáže, že čísla nesedí.

Zpravidla je nutné upravenou hodnotu do Mety posílat přes Meta Conversions API (CAPI). Samotný pixel v prohlížeči na marži po řádcích nestačí, hlavně po omezeních cookies a blokování měření. CAPI přes server-side GTM obvykle změří víc konverzí spolehlivěji než samotný pixel.

Jak je to postavené

1. Google Tag Manager na serveru přečte událost nákupu z GA4, dotáhne marže k produktům, vynásobí koeficientem a odešle upravenou hodnotu do reklamních systémů.
2. Firestore drží aktuální marže po SKU. Při dokončení nákupu potřebujete číst v řádu milisekund. K tomu je Firestore přes server-side GTM praktický. BigQuery v tu chvíli nepoužívejte.
3. BigQuery (nebo jiný datový sklad) spojuje nákupní ceny z ERP nebo e-shopu s prodeji a denně přepočítává marže po SKU. Výsledek synchronizujete do Firestore.

Alternativní postup: webové GTM a dataLayer

Pro Google Ads i Metu lze marži posílat i přes webové GTM a dataLayer, pokud máte plnou kontrolu nad daty objednávky v okamžiku nákupu. U krabicových řešení typu Shoptet to často nevyjde: omezená customizace, závislost na šabloně a doplňcích. Spíš pro e-shop s vlastním vývojářem, který umí do dataLayer poslat marži po položkách objednávky.

Hlavní nevýhoda browser cesty: hodnoty uvidíte v záložce Network a v DevTools je může dohledat kdokoli v prohlížeči, včetně konkurence. I pod koeficientem nejsou marže přímo jako procenta, ale signál o struktuře zisku tam jde odhalit. Proto raději server-side GTM a u Mety CAPI.

Navíc u browser cesty bývá problém s kvalitou dat: špatně převedené měny a kurzy, nulové hodnoty marže, chybějící řádky. DataLayer beru jako nouzovou nebo testovací variantu.

V jakém pořadí to řešit

Obvykle doporučuji nejdřív nasadit segmentaci produktů v Google Ads. Za mě přináší větší posun než úprava hodnoty konverze, dokud neřešíte, která SKU vám pálí rozpočet.

Technicky jde nasadit segmentaci, marži i akvizici najednou. Za mě ale často dává smysl dva kroky: nejdřív segmentace produktů v kampaních, mezitím na pozadí připravit nebo nechat sbírat data pro tento článek a import akvizice a retence, pak druhou vlnu zapnout společně. Segmentace mezitím běží, nečekáte zbytečně na marži. Pokud si nejste jistí, kde začít, za mě má největší cenu segmentace.