Recept: profitkövetés és POAS-alapú licitálás

A rendelések profitjának jelentése a bevétel mellett, hogy a kampányokat a hirdetési költségre jutó profitra optimalizálhasd.

Ez a recept a rendelések profitját jelenti a bevétel mellett, így a kampányokat a hirdetési költségre jutó profitra (POAS) optimalizálhatod a hirdetési költségre jutó bevétel (ROAS) helyett. Két azonos ROAS-ú kampány mögött nagyon eltérő profit lehet, és a különbség többnyire a termékmixből jön.

Amit a Pixel Manager már tud

Ha be van kapcsolva az egyik támogatott beszerzésiköltség-forrás (lásd: Bolt beállításai), a Pixel Manager rendelésenként kiszámolja a haszonkulcsot: a termékbevételből levonja a beszerzési költséget, a kedvezményeket, a visszatérítéseket és a fizetésszolgáltatói díjakat. Minden érték adó nélküli (nettó).

Két dolgot nem tud, és nem is tudhat:

Mennyit számláz neked a szállító. A WooCommerce azt rögzíti, mennyit számláztál a vevőnek a szállításért, de azt nem, hogy neked mennyibe került. A szállítás ezért mindkét oldalról kimarad a haszonkulcsból.
Be van-e állítva a termék költsége. A költség nélküli termék nulla költséggel számít, vagyis a teljes bevétele csendben profitként jelenik meg.

Mindkettőt pótolni lehet az alábbi lépésekkel.

1. lépés: a szállítási gazdaságosság beépítése a haszonkulcsba

A kézenfekvő megvalósítás azt kérdezi, számláztál-e szállítást a vevőnek:

if ($order->get_shipping_total() > 0) {
    $courier_cost = 34.00;
}

Ez helyesnek látszik, de hibás. Az ingyenes szállítási küszöb fölött a vevő nem fizet semmit, a feltétel hamis, nem vonódik le futárköltség, a csomag viszont ugyanúgy elmegy. Egy fix díjas futárszerződésnél 400-as küszöb mellett ez az adott rendelés bevételének nagyjából 8,5%-át adja csendben a profithoz.

Miért rosszabb ez a hiba a profitkövetés hiányánál? A torzulás nem véletlenszerű: teljes egészében a legnagyobb rendelésekre esik, és mindig felfelé húz. A kampányokat profit alapján összehasonlítva a nagy kosárértékű kampányok rendszeresen túlbecsültnek látszanának, és olyan okból csoportosítanál feléjük költségvetést, ami nem létezik. A felfedezésnek látszó hiba rosszabb, mint a hiányzó szám.

A futárköltséget a szállítási módból döntsd el, ne a felszámolt összegből. A mód megmondja, van-e futár a képben, az összeg csak azt, mennyit fizetett a vevő, ami más kérdés.

function my_shop_courier_cost($order) {
    $methods = $order->get_shipping_methods();

    if (empty($methods)) {
        return 0.0;
    }

    foreach ($methods as $method) {
        $id = $method->get_method_id();

        if ('local_pickup' === $id || false !== strpos($id, 'pickup')) {
            return 0.0;
        }
    }

    return 34.0;
}

add_filter('pmw_order_shipping_profit', function ($shipping_profit, $order) {
    return (float) $order->get_shipping_total()
         - (float) $order->get_total_shipping_refunded()
         - my_shop_courier_cost($order);
}, 10, 2);

A pmw_order_shipping_profit szűrő az 1.67.1-es változattól érhető el. A bevételi oldal egyszerűen a get_shipping_total() visszaadása, mert a számítás kihagyta, a visszatérített szállítást pedig levonja a képlet, mert a haszonkulcsban semmi más nem vonja le.

Mértékegység: minden érték nettó. A get_shipping_total() nettó összeget ad, ezért a futárdíjnak is nettónak kell lennie. Egy számpélda: a vevő 37-et fizet 18% áfával, ez nettó 31,36. A futár nettó 34-et számláz. A szállítás tehát nettó körülbelül 2,64 veszteség rendelésenként, nem nyereség, ami a bruttó számok alapján éppen fordítva látszana. Áfás országban könnyű elrontani, mert a rendelés képernyőjén minden szám bruttó, a számítás viszont nettóban dolgozik. Ha az adminfelületről veszed a 37-et, vagy bruttó futárdíjat írsz be, minden rendelésnél az áfa összegével tévedsz: rendelésenként kevés, de rendszeres és láthatatlan hiba.

Két szállítási sor. Ha egy rendelés két szállítási sorra oszlik, a fix költség egyszer számít. Ha bontott szállítást használsz, soronként számolj.

2. lépés: a profit elküldése a Google Analyticsbe és a Google Adsbe

A pmw_custom_order_parameters szűrő egy paramétert tesz a Google Analyticsnek küldött vásárlási eseményre, amelyet ott egyedi metrikaként regisztrálhatsz. Ugyanez az érték a böngészőben egy második Google Ads konverziós művelethez is elérhető.

add_filter('pmw_custom_order_parameters', function ($custom_parameters, $order) {

    if (!class_exists('\SweetCode\Pixel_Manager\Profit_Margin')) {
        return $custom_parameters;
    }

    if (!\SweetCode\Pixel_Manager\Profit_Margin::order_has_complete_cogs($order)) {
        return $custom_parameters;
    }

    $custom_parameters['profit'] = round(
        (float) \SweetCode\Pixel_Manager\Profit_Margin::get_order_profit_margin($order),
        2
    );

    return $custom_parameters;
}, 10, 2);

Az order_has_complete_cogs() az 1.67.1-es változattól érhető el. A költségkeresést ne írd újra magad: a meta kulcsok forrásonként, változatonként, valamint a rendelési tétel és a termék között is eltérnek, és egy részleges lista másolása csendben semmit sem talál.

Ezután jelentsd a profitot második Google Ads konverziós műveletként, a Pixel Manager által küldött bevételi művelet mellett:

add_action('wp_head', function () {
    ?>
    <script>
        window._pmwq = window._pmwq || [];
        window._pmwq.push(function () {
            pmw.bus.on("pmw:event:purchase", function () {
                var order = window.pmwDataLayer && pmwDataLayer.order;
                if (!order || !order.custom_parameters) return;

                var profit = parseFloat(order.custom_parameters.profit);
                if (!isFinite(profit)) return;

                pmw.trackCustomGoogleAdsConversion("AW-CONVERSION_ID/CONVERSION_LABEL", {
                    value         : Math.max(0, profit),
                    currency      : order.currency,
                    transaction_id: String(order.number)
                });
            });
        });
    </script>
    <?php
});

A pmw.trackCustomGoogleAdsConversion() az 1.67.1-es változattól érhető el, és magától alkalmazza a marketing-hozzájárulás kapuját, valamint megvárja a Google-címkét (lásd: Tippek és trükkök). A kódrészletben négy részlet számít:

Minden oldalra írd ki, wp_head oldalfeltétel nélkül. A vásárlási esemény a kapu, és az Automatic Conversion Recovery egy átlagos bolti oldalon is elsüti, amikor a vevő olyan rendeléssel tér vissza, amelyet nem követtek. A csak a megerősítő oldalra szóló kódrészlet pontosan ezeket a rendeléseket hagyja ki.
A pmw:event:purchase eseményre akaszd, soha ne a pmw:ready eseményre vagy a window.gtag meglétének ellenőrzésére. Ahol a JavaScript halasztva vagy késleltetve fut, az adatréteget a PHP jóval a követőcsomag előtt kiírja, ezért a gtag ilyenkor biztosan hiányzik, a pmw:ready pedig nem játszódik vissza újra (lásd: JavaScript-események). A pmw:event:purchase visszajátszódik.
A transaction_id az order.number legyen, ugyanaz az azonosító, amelyet a Pixel Manager saját konverziója küld, hogy mindkét művelet ugyanarra a rendelésre kulcsolódjon.
Az értéket nullánál ne engedd lejjebb. Erősen visszatérített rendelésnél a profit negatív lehet, a hirdetési platformok pedig vagy elutasítják, vagy félreértik a negatív értéket.

Regisztráld a profit paramétert a Google Analyticsben eseményszintű egyedi metrikaként, és számíts egy nap feldolgozási időre, mielőtt megjelenik a jelentésekben.

3. lépés: tudd, mit jelent a bevételi művelet

Ha a fizetésszolgáltatói díjakat a pmw_order_fees szűrőn át adod meg (lásd: PHP-szűrők: értékek, azonosítók és profit), az nemcsak a haszonkulcsot táplálja. A Order Subtotal értéklogikánál a marketingpixeleknek küldött értéket is csökkenti, így a bevételi konverziós műveleted a díj bevezetése napjától a díjjal csökkentett részösszeget jelenti. A két művelet így összehasonlíthatóbb, de a jelentett adatsorban lépcsőszerű változás lesz, amelyet a beállításokban semmi nem magyaráz.

Ne vonj le egy költséget kétszer. A haszonkulcsból a pmw_order_fees már le van vonva. Ha a díjat ott és a saját profitszámításodban is levonod, kétszer számít. Ugyanez igaz attól a naptól, hogy a Marketing value logic beállítást Profit margin értékre állítod: a hirdetési platformoknak küldött érték ekkor már tartalmazza a fizetési díjat és a szállítási szűrődet, ezért vedd ki mindazt, amit kézzel adtál még hozzá.

Tesztelés

Adj le egy tesztrendelést, és ellenőrizd, hogy a paraméter megérkezik a böngészőbe: pmwDataLayer.order.custom_parameters;
Adj le egy második rendelést olyan termékkel, amelynek nincs beállított költsége, és ellenőrizd, hogy a custom_parameters nem tartalmazza a profitot, és nem fut le profitkonverzió.
Adj le egy harmadikat olyan szállítási móddal, amely az ingyenes szállítási küszöb fölött van, és ellenőrizd, hogy a futárköltség így is levonódik. Ezt az esetet rontja el a kézenfekvő megvalósítás.
A konverziók számát a Google Adsben ellenőrizd, ne a böngésző Network paneljén. Egy konverzió több Google-végpontra szétterjed, ezért egyetlen hívás több kérést is okoz.

A megerősítő oldal újratöltése nem váltja ki újra a vásárlást. Ugyanazzal a rendeléssel való újratesztelésért fűzd a megerősítő oldal URL-jéhez a ?nodedupe paramétert, és kapcsold be a konzolnaplózót a ?pmwloggeron paraméterrel, hogy lásd az eseményfolyamot.

Kapcsolódó fejezetek: Bolt beállításai, PHP-szűrők: értékek, azonosítók és profit, Tippek és trükkök, JavaScript-események.

Készült: 2026. november 1.