Stejná tržba, jiný zisk
Google Ads i Meta se svými automatickými strategiemi (Target ROAS, Maximize Conversion Value) učí přesně na tom, jaké číslo jim pošlete jako hodnotu konverze. Ve výchozím nastavení to je tržba dokončené objednávky. Reklamní systém tak vidí, kolik e-shop utržil, ale ne, kolik z toho reálně zbylo po odečtení nákupní ceny zboží.
Stejná tržba, jiný zisk
Dvě objednávky po 1 000 Kč vypadají v účtu Google Ads úplně stejně. Z jedné může zbýt 50 Kč marže, z druhé 400 Kč. Rozdíl je v mixu produktů, a pokud do systému posíláte jen tržbu, algoritmus ho nevidí a nemá podle čeho preferovat tu ziskovější objednávku.
Import marže znamená import skutečného zisku jako signálu
Import marží je proces, kterým se nákupní ceny z účetnictví, ERP nebo e-shopu dostanou do reklamního systému jako hodnota konverze místo tržby. Kampaň pak neoptimalizuje na to, kolik se prodalo, ale na to, kolik firma na prodeji reálně vydělala.
Nemá smysl vždy
Pokud je marže napříč sortimentem podobná, import marže výsledek výrazně nezmění a stačí optimalizace na tržbu. Vyplatí se hlavně tam, kde se marže mezi produkty nebo kategoriemi výrazně liší.
Kde firmy pálí peníze
Typická chyba: reklamní systém je nastavený na hodnotu objednávky nebo počet konverzí, bez informace o marži. Algoritmus pak neví, který produkt je pro firmu výhodný a který prodělečný, a rozpočet rozděluje rovnoměrně nebo podle obratu, ne podle zisku.
Optimalizace na tržbu bez ohledu na marži
Kampaň, která maximalizuje hodnotu konverze počítanou z tržby, klidně přesune rozpočet k produktu s vysokým obratem a nízkou marží, a bude to vypadat jako úspěch, dokud se čísla nepodívají na zisk.
Přepnutí hodnoty konverze rovnou na primární cíl
Kdo změní hodnotu existující konverze z tržby na marži a rovnou ji nechá jako primární cíl optimalizace, riskuje, že automatické nabídky ztratí historickou distribuci, na které se učily. Restart učení pak znamená týdny nestability podle objemu konverzí.
Posílání marže bez koeficientu
Když se do účtu pošle marže místo tržby, součet konverzních hodnot spadne úměrně průměrné marži, při 30 % zhruba na třetinu. Reklamní systémy na nižší čísla reagují horším doručováním. Bez přepočtu, který sníženou hodnotu vyrovná, výkon kampaně jednoduše propadne.
Roztříštěná nebo nekvalitní data o marži
Rozštěpené zdroje, tabulky po dodavatelích a značkách, chybějící nebo neaktuální nákupní ceny, nebo párování produktů mezi měřením a e-shopem, ERP či skladovým systémem, které nesedí. Kdo pošle marži do reklamy z takhle nekonzistentních dat, neoptimalizuje na zisk, ale na šum.
Jeden zdroj marže, denně přepočítaný po SKU
Import marží stavíme na jednom sjednoceném zdroji dat, ne na ručním exportu z jednoho konkrétního systému. Datový sklad (typicky BigQuery) spojuje nákupní ceny z ERP nebo e-shopu s prodeji a denně přepočítává marže po jednotlivých SKU. Funguje to se Shoptetem, UpGates, Abrou, Pohodou nebo libovolným jiným API exportem či feedem, princip zůstává stejný bez ohledu na to, odkud přesně nákupní ceny přicházejí.
Denní přepočet po SKU, ne jednorázový export
Marže se u produktu mění, mění se nákupní cena i akční cena v e-shopu. Denní přepočet po SKU zajišťuje, že hodnota, kterou reklamní systém dostane, odpovídá aktuální marži, ne stavu z minulého měsíce.
Koeficient, aby se udržela hodnota konverzí
Marže se do reklamy neposílá napřímo, ale vynásobená koeficientem rovným převrácené hodnotě průměrné marže (při průměru 30 % zhruba 3,3 až 3,6). Součet hodnot konverzí tak zůstane na podobné úrovni jako dřív, jen se přerozdělí váha mezi ziskovými a méně ziskovými objednávkami, a systém nezačíná učení od nuly.
Nejdřív ověřit jako sekundární konverzi
Novou konverzi s hodnotou z marže zakládáme jako sekundární, necháváme běžet minimálně 14 až 30 dní a kontrolujeme, že počet a hodnota konverzí odpovídají původní konverzi na tržby. Teprve pak se přepíná primární cíl optimalizace. Tenhle krok chrání účet před restartem učení, ke kterému dochází při unáhleném přepnutí.