Zbieranie jakościowych informacji pozwala na szersze zastosowanie danych wykraczające poza standardowy paradygmat myślenia o tym, w jaki sposób można analizować rzeczywistość, a co za tym idzie, między innymi cyfrowy biznes. Jedną z możliwości jest prognozowanie wyników, technika umożliwiająca przewidywanie przyszłości w stosownym horyzoncie przy zachowaniu odpowiednio wcześnie ustalonych reguł. W jaki sposób to można wdrożyć dla e-commerce przy użyciu Google Analytics 4?

Co to jest prognozowanie? Dlaczego jest ważne? Jak to firmy robią?

Prognozowanie to termin, który opisuje proces używania danych do przeniesienia wzorców i trendów w przyszłość. Jest to umiejętność przewidywania przyszłych zdarzeń, potrzeb lub zachowań na podstawie informacji, które już posiadamy. W kontekście biznesu, prognozowanie pozwala na tworzenie modeli i scenariuszy, które pomagają firmom przewidzieć przyszłe wyniki, a także zidentyfikować potencjalne możliwości lub zagrożenia. stanowi fundamentalne narzędzie dla strategicznego zarządzania firmą. Umożliwia identyfikację trendów, które mogą mieć wpływa na jej funkcjonowanie w przyszłości. Przewidywanie przyszłych wyników, czy to sprzedaży, popytu czy sytuacji na rynku, pozwala firmie przewidywać swoje potrzeby, planować strategie i podjąć decyzje, które pomogą jej osiągnąć cele w przyszłości.

Prognozowanie jest tak szerokim pojęciem, że obejmuje wiele technik, ale skupmy się na kilku najbardziej popularnych, które opierają się na matematyce, statystyce i socjologii:

• Proste metody statystyczne: Prosta metoda statystyczna, jak linia trendu, polega na dopasowaniu linii do historycznych danych w celu wyznaczenia przyszłych kierunków trendów. Inną prostą metodą jest średnia ruchoma, która polega na obliczeniu średniej z określonej liczby ostatnich obserwacji. Te metody są łatwe do zrozumienia i implementacji, ale mogą nie być wystarczająco skuteczne, kiedy dane są zmiennym i mają skomplikowane wzorce sezonowe.
• Sondaże i badania rynku: Czasami firmy stosują techniki prognozowania oparte na badaniach rynku, takie jak ankiety, wywiady czy grupy dyskusyjne, aby przewidzieć popyt na nowy produkt lub usługę. Metoda ta polega na bezpośrednim zapytaniu klientów o ich plany i przyzwyczajenia zakupowe.
• Prognozowanie oparte na modelach przyczynowych: Inne techniki prognozowania polegają na użyciu modeli przyczynowych, które zakładają istnienie zależności między danymi, które chcemy przewidzieć, a innymi danymi. Przykładem jest regresja. Można stwierdzić, że sprzedaż lodów w upalny dzień jest zależna od temperatury. Poprzez regulację różnych zmiennych, takich jak temperatura, możemy przewidywać przyszłą sprzedaż lodów.
• Analyza szeregów czasowych: Techniki te analizują dane historyczne, aby znaleźć ukryte wzorce i trendy, które można następnie wykorzystać do prognozowania przyszłości. Przykładowo, popularny model ARIMA (ang. AutoRegressive Integrated Moving Average) jest często stosowany do analizy szeregów czasowych.
• Metody oparte na sztucznej inteligencji: Algorytmy uczenia maszynowego, takie jak sieci neuronowe, lasy losowe i algorytmy boostingu gradientowego, stają się coraz częściej stosowane w prognozowaniu biznesowym. Są w stanie przetwarzć ogromne ilości danych i identyfikować skomplikowane wzorce, które mogą umknąć prostszym technikom prognozowania.

Ostatecznie, efektywność prognozowania jest zależna od kontekstu i specyfiki danej firmy. Najistotniejsze w prognozowaniu jest zrozumienie, które metody są najskuteczniejsze w danym kontekście i dostosowanie techniki do specyfiki sektora, w którym firma działa.

Jak prognozować dane w marketingu i łączyć to z biznesem? Najważniejsze wyzwania

Istotne w tym momencie jest zrozumienie perspektyw jakimi rządzi się zarządzanie biznesem i zarządzanie marketingiem:

• Marketing z założenia to działania, które podejmuje się, by promować produkty lub usługi. Jednocześnie jest on w stanie bardzo często dostarczać informację zwrotną na temat tego, w jaki sposób funkcjonuje nasz produkt lub usługa, jak prezentuje się cena, czy jest całość dopasowana do potrzeb końcowego klienta itd., co za tym idzie, funkcjonuje on w sposób nieliniowy. Trudność w tym wszystkim zwiększa to, że jest względnie niska świadomość osób decyzyjnych na temat technik badawczych, statystycznych i zagadnień technicznych, przez co wiele decyzji jest podejmowanych m.in:
  • w sposób nieprzemyślany pod kątem potencjalnego ich mierzenia: niewłaściwy dobór kryteriów i metryk, sprowadzanie marketingu wyłącznie do procesu reklamowania, a w zasadzie zakupu mediów (który też z powodu mnogości platform reklamowych, zróżnicowanych definicji i ich zróżnicowanych konstrukcji jest mocno względny)
  • życzeniowo: bardzo często estymacje to de facto lista pobożnych celi na potrzeby kreowania rzeczywistości, którą
  • zbyt dokładnie: poprzez doszukiwanie się korelacji w miejscach, gdzie ich nie ma
• Biznes z kolei obejmuje nie tylko marketing, ale więcej obszarów (np. logistykę, produkcję), gdzie jest często możliwy dokładny pomiar niektórych procesów (np. produkcyjnych) i ich optymalizacja, co często skutkuje mocno linowym spojrzeniem na chociażby planowanie finansowe (gdzie marketing nie musi wykazywać korelacji między np. zasięgami, a poziomem sprzedaży).

W istocie tworzy się naturalna symbioza, w ramach której biznes od marketingu dostaje dane nie tylko ilościowe (ilość użytkowników, ilość dodań do koszyka, zakupy, poziom retencji), ale także jakościowe (jak chociażby wywiady od użytkowników, satysfakcja z używania produktu, badania społeczne) używane na potrzeby nie tylko planowania, ale także procesu odkrywania produktu i tworzenia szerszej strategii rozwoju biznesu.

Marketing z kolei gros danych pozyskuje reklamowania się, czyli konkretnych produktów reklamowych i systemów analizujących zachowania w czasie rzeczywistym lub historycznie. Biznes z kolei pozyskuje dane chociażby z produkcji, by np. oszacować, ile będzie kosztować potencjalny pokrycie podaży w odpowiedzi na popyt, o którym poinformował marketing.

Reklamy jako jedno z krytycznych źródeł (wbrew przeciwstawnej, obiegowej opinii, która jest w moim mniemaniu błędna) informacji rządzą się swoimi prawami, w ramach których m.in.:

• dostawcy powierzchni reklamowej konkurują ze sobą, co nie sprzyja wymianie informacji między systemami w celu np. atrybuowania ścieżki użytkownika;
• potrafią być rozbieżne pojęcia, np. w zakresie tego, co jest konwersją lub wyświetleniem (a może być błędnym sygnałem co do określania chociażby potencjalnego momentum sprzedażowego na podstawie danych historycznych);
• nie są udostępniane niektóre informacji, czego przyczyny są różne — od tego, że informacje te mogą być faktycznie niepotrzebne, poprzez indywidualne ustalenia, kończąc na tym, że dany produkt z przyczyn bliżej nieokreślonych konkretnych metryk nie udostępnia;

Istotnym elementem jest to, że niektórych zachowań nie można pomierzyć, na co wpływ mają regulacje prawne i zmiany technologiczne, które chociażby blokują przesyłanie niezbędnych danych przez użytkowników.

Znając już podstawy tego, w jaki sposób można określać prognozy oraz ryzyka z nich wynikających, można przejść do tego, w jaki sposób nowoczesne narzędzia marketingowe, w tym Google Analytics 4, przewidują rezultaty.

Jak działa prognozowanie w Google Analytics 4?

Google w narzędziu Google Analytics 4 dokonał implementacji metryk predykcyjnych, które na podstawie danych z sesji użytkowników i (co jest warte zaznaczenia i zapamiętania) zamkniętego modelu od Google prognozuje:

• Prawdopodobieństwo zakupu: Prawdopodobieństwo, że użytkownik, który był aktywny w ciągu ostatnich 28 dni, wywoła w ciągu najbliższych 7 dni zarejestrowanie określonego zdarzenia konwersji.
• Prawdopodobieństwo rezygnacji: Prawdopodobieństwo, że użytkownik, który w ciągu ostatnich 7 dni był aktywny w witrynie lub aplikacji, nie będzie aktywny w ciągu najbliższych 7 dni.
• Prognozowane przychody: Przychody oczekiwane w ciągu najbliższych 28 dni ze wszystkich konwersji polegających na zakupie, które przypuszczalnie wykona użytkownik aktywny w ostatnich 28 dniach.

Dzięki temu można stworzyć dedykowaną grupę odbiorców, którzy np. w danym przedziale czasu mają największe prawdopodobieństwo na zakup, przez co można skierować na nią specjalny komunikat marketingowy poprzez Google Ads.

Aby skutecznie trenować modele prognozujące, Google Analytics wymaga spełnienia tych kryteriów:

1. Minimalnej liczby pozytywnych i negatywnych przykładów użytkowników skłonnych do zakupów lub rezygnacji. Wymagane jest, aby przez 7 kolejnych dni przypadających w ciągu ostatnich 28 dni co najmniej 1000 powracających użytkowników spełniło odpowiedni warunek prognostyczny (zakup lub rezygnacja) i co najmniej 1000 powracających użytkowników nie spełniło tego warunku.
2. Utrzymywania przez pewien czas odpowiedniej jakości modeli prognostycznych
3. Aby kwalifikować się do korzystania z danych dotyczących prawdopodobieństwa zakupu i prognozowanych przychodów, usługa musi wysyłać zdarzenia zakupu

Dane prognozowane w przypadku każdego kwalifikującego się modelu będą generowane raz dziennie dla każdego aktywnego użytkownika. Jeśli jakość modelu w usłudze spadnie poniżej minimalnego progu, Google Analytics przestanie aktualizować odpowiednie prognozy i mogą się one stać niedostępne. Niezbędne jest w takiej sytuacji włączenie funkcji Modeling contributions & business insights z sekcji Data sharing.

Warto pamiętać o modelowaniu behawioralnym, które jest mocno powiązanym mechanizmem służącym do minimalizowania niedogodności związanych ze zmianami protokołów prywatności (czyli estymowania tego, ile np. użytkowników odwiedza nasz serwis), a następnie prognozowania: w końcu w taki sposób dostajemy informacje, na podstawie których trenujemy modele, warto więc by były jak najbardziej dokładne (czyli były tak bardzo prawdopodobne jak to możliwe). Oprócz samego wdrożenia Google Tag Manager Server-Side rekomenduję (co jest również wymagane na terenie EOG) sprawdzić, czy consent mode za pomocą Consent Management Platform jest prawidłowo wdrożony.

Darmowe wdrożenie consent mode

Artykuł omawia znaczenie i korzyści zastosowania Consent Management Platform (CMP) dla zgodności ze standardami prywatności. Porównywane są wady i zalety darmowych oraz płatnych narzędzi CMP.

Kacper DurasKacper Duras

Zmiany w przepisach dotyczące prywatności, respektowania zgód przetwarzania danych osobowych i pokrewnych informacji narzucają jako jeden z wymogów respektowanie prawidłowej zgody na pliki cookies. Ciasteczka to wysyłane przez serwis internetowy, który odwiedzamy ładunki informacji, zapisywane na urządzeniu końcowym (komputerze, laptopie, smartfonie), z którego korzystamy podczas przeglądania stron internetowych.

Do zarządzania mechanizmami zgody (w tym consent modę), a co za tym idzie, nie tylko zgodą na zapisywanie ciasteczek (ale również uruchomienie innych narzędzi i realizację stosownych akcji, które spełniają stosowną kwalifikację prawną), służy narzędzie nazywane zbiorczo Consent Management Platform. Najpopularniejsze tego usługi potrafią być nieproporcjonalnie drogie względem tego, co one faktycznie oferują. Jakie są alternatywy?

Dlaczego muszę wdrożyć Consent Management Platform?

Wdrożenie Consent Management Platform (CMP) jest istotne z wielu powodów:

1. Dostosowanie do przepisów: Przepisy o ochronie danych, takie jak RODO w Unii Europejskiej, nakładają na firmy obowiązek uzyskania wyraźnej zgody od użytkowników na gromadzenie i przetwarzanie ich danych osobowych. CMP pomaga firmom spełnić te wymagania.
2. Zgodność z wymogami platform reklamowych: Wiele platform reklamowych (w tym najwięksi gracze jak Google) wymaga, aby firmy korzystające z ich usług, przestrzegały określonych zasad dotyczących zbierania i przetwarzania danych użytkowników. CMP umożliwia firmom spełnienie tych wymagań.
3. Transparentność: Dzięki CMP, użytkownicy mogą lepiej zrozumieć, na co dokładnie wyrażają zgodę, jeśli chodzi o gromadzenie i wykorzystywanie ich danych.
4. Personalizacja: Kiedy użytkownicy wyrażają zgodę na przetwarzanie ich danych, firmy są w stanie co do zasady lepiej dostosować swoje reklamy i oferty do indywidualnych preferencji użytkowników (consent modę). Można to uzyskać np. za pomocą wdrożenia Google Tag Manager Server-Side.
5. Zmniejszenie ryzyka: CMP pomaga zminimalizować ryzyko naruszenia ochrony danych, ponieważ firmy mają jasne wytyczne dotyczące tego, jakie informacje mogą zbierać i w jaki sposób je wykorzystywać.
6. Efektywność: Użycie CMP pozwala sprawniej zarządzać zgodami użytkowników, co przekłada się na oszczędność czasu i zasobów, zarówno dla strony, jak i dla użytkowników.

Konieczność posiadania CMPka jest korzystna dla większości stron. Najbardziej cierpią na tym reklamodawcy, którzy nie mają możliwości dokładnego pomiaru danych tak, jak to się działo dotychczas. Istotny jednak niezależnie od wyznawanego poglądu jest aspekt kosztowy wdrożenia rozwiązania.

Darmowe rozwiązania vs płatne narzędzia - plusy i minusy

W większości sytuacji jestem zwolennikiem używania płatnych CMPków ze względu na dbanie o zgodność z aktualnym i prostotę wdrożenia, acz rozumiem też osoby, które za wszelką cenę chcą zwalczać zbędne koszty. Przygotowałem poniżej porównanie pomocne we wyborze ścieżki decyzyjnej.

Darmowe CMP

Plusy:

• Bez finansowanych kosztów początkowych: Brak opłat związanych z wdrożeniem i utrzymaniem.
• Dostępność: Zazwyczaj łatwo dostępne dla wszystkich, niezależnie od wielkości firmy czy budżetu.
• Prostota: Darmowe opcje mogą być łatwiejsze do implementacji, z co stanowi korzyść dla mniejszych firm lub tych, które dopiero zaczynają swoją przygodę z zarządzaniem zgodami.

Minusy:

• Brak wsparcia technicznego: Ten rodzaj narzędzi często nie zapewnia wsparcia technicznego lub oferuje go w ograniczonym zakresie. Darmowy CMPek wymuszą najczęściej napisanie większości funkcjonalności samodzielnie (w tym implementacji z mechanizmem zgód). To, w jaki sposób będzie on zoptymalizowany i skonstruowany zależy głównie od programisty.

Płatne CMP

Plusy:

• Zaawansowane funkcje: Płatne narzędzia często oferują szereg zaawansowanych funkcji, które mogą pomóc firmom lepiej wykorzystać swoje dane.
• Wsparcie i edukacja: Płatne platformy zazwyczaj oferują wsparcie techniczne, a czasem nawet szkolenia i materiały edukacyjne.
• Aktualizacje i rozwój: Obecność regularnych aktualizacji i dodatkowym komponentów gwarantuje, że platforma będzie na bieżąco z przepisami prawnymi i najnowszymi trendami.
• Większa kontrola i bezpieczeństwo: Firmy mogą skorzystać z pełnej kontroli nad danymi i zgodami, a także lepszą ochronę danych dzięki zaawansowanym zabezpieczeniom.

Minusy:

• Koszt: Główną wadą jest konieczność ponoszenia miesięcznych lub rocznych opłat za narzędzie.
• Długoterminowe zobowiązanie: Niektóre płatne platformy wymagają długoterminowych umów, które mogą być trudne do zerwania.

Jeśli wiesz jak faktycznie wdrożyć CMP i masz możliwość realizowania konsultacji prawnych w zakresie przetwarzania danych (gdzie nie mam tutaj na myśli kupowania wzorów najważniejszych dokumentów), to wdrożenie własnego CMPka ma sens. Jest to mniejszość scenariuszy przeze mnie zalecanych i jak wspomniałem we wstępie, jeśli masz możliwość, to skorzystaj z gotowego produktu.

Alternatywnie możesz skorzystać ze systemów do zarządzania kodami śledzącymi jak np. Cloudflare Zaraz, gdzie CMP ze stosownym widgetem jest wbudowany w narzędzie:

Integracja narzędzi analitycznych przy pomocy Cloudflare Zaraz

Z postępującym rozwojem technologicznym w sektorze reklamy pojawiają się innowacyjne metody umożliwiające efektywniejsze ocenianie wyników działań marketingowych, jednocześnie respektujące wymagane przepisy. Podobną funkcję pełni Cloudflare Zaraz.

Kacper DurasKacper Duras

Jak wdrożyć Consent Management Platform za darmo?

Jeśli decydujesz się na darmowe wdrożenie i masz wiedzę programistyczną lub zasoby do wdrożenia to możesz skorzystać z jednego z gotowych frameworków - najprostszym do implementacji jaki znalazłem jest Klaro.

Instrukcja jest bardzo prosta i składa się z następujących elementów:

• załączenie skryptów GTM, następnie iniekcja skryptów od Klaro
• przygotowanie dedykowanej konfiguracji - tutaj przykład uwzględniający zmiany związane z CMP v2 od Google

var klarConfig = {
    acceptAll: true,
    services: [
        {
            name: 'google-tag-manager',
            required: true,
            purposes: ['marketing'],
            onAccept: `
                for (let k of Object.keys(opts.consents)) {
                    if (opts.consents[k]){
                        let eventName = 'klaro-'+k+'-accepted'
                        dataLayer.push({'event': eventName});
                    }
                }
            `,
            onInit: `
                window.dataLayer = window.dataLayer || [];
                window.gtag = function() {
                  dataLayer.push(arguments)
                }
                
                gtag('consent', 'default', {
                  'ad_storage': 'denied', 
                  'analytics_storage': 'denied', 
                  'ad_user_data': 'denied', 
                  'ad_personalization': 'denied'
                })
                gtag('set', 'ads_data_redaction', true)
            `,
        },
        {
            name: 'google-analytics',
            cookies: [
                /^_ga(_.*)?/
            ],
            purposes: ['marketing'],
            onAccept: `
                gtag('consent', 'update', {
                    'analytics_storage': 'granted',
                })
            `,
            onDecline: `
                gtag('consent', 'update', {
                    'analytics_storage': 'denied',
                });
            `,
        },
        {
            name: 'google-ads',
            cookies: [],
            onAccept: `
                gtag('consent', 'update', {
                    'ad_storage': 'granted',
                    'ad_user_data': 'granted',
                    'ad_personalization': 'granted'
                });
            `,
            onDecline: `
                gtag('consent', 'update', {
                    'ad_storage': 'denied',
                    'ad_user_data': 'denied',
                    'ad_personalization': 'denied'
                });
            `,
            purposes: ['marketing'],
        }
    ]
};

• wytestowanie implementacji za pomocą podglądu w Google Tag Manager (oraz obsługa zdarzenia zmiany)

Podsumowując, rola Consent Management Platform (CMP) w dzisiejszym cyfrowym świecie zasługuje na szczególną uwagę. Narzędzie to jest nie tylko kluczem do zgodności z przepisami prawnymi, ale również do budowania zrozumienia i zaufania wśród użytkowników. Optymalna decyzja o tym, czy warto zainwestować w płatne narzędzie CMP, czy skorzystać z darmowego, zależy od konkretnej sytuacji i potrzeb firmy, a w szczególności od jej wielkości, budżetu i poziomu złożoności działań marketingowych.

Zamknij oczy i wyobraź sobie, że jesteś na wielkim, głośnym bazarze. Kupcy z całego świata oferują swoje towary, a ty jesteś w centrum tego handlowego wiru, szukając okazji, które przyciągną twoją uwagę. Teraz wyobraź sobie, że masz przy sobie osobistego asystenta, który zna twoje preferencje i potrafi negocjować za ciebie, gwarantując najlepsze możliwe oferty. Brzmi wyjątkowo, prawda? W świecie cyfrowym, tę rolę asystenta przejmuje coraz częściej technologia - a konkretnie - automatyczne rabaty w Google Ads.

To, co mogło wydawać się niemożliwe, dziś staje się rzeczywistością dzięki ciągłemu postępowi technologicznemu. Ale, jak to wszystko działa? Jakie są tajemnice zawarte za tymi intrygującymi narzędziami, które zdają się zmieniać zasady gry w e-commerce?

Czym są automatyczne rabaty w Google Ads i jak działają?

Automatyczne rabaty są funkcjonalnością produktu Google Ads, która umożliwia elastyczne zarządzanie polityką cenową dla produktów oferowanych w e-commerce przez kampanie reklamowe. Dzięki temu Google na podstawie swoich danych i w zależności od między innymi popytu, konkurencji i celu konkretnej kampanii, jest w stanie wyróżnić konkretną ofertę proponując stosowny rabat dla końcowego użytkownika i skłonić go do zakupu w danych sklepie internetowym w ograniczonym przedziale czasu (domyślnie: 1 godzina).

Jest to ciekawą alternatywą dla standardowego systemu rabatowego, iż:

• personalizuje wrażenie zakupowe dla użytkownika: sklep nie musi proponować rabatu jako stałego cennika (bardzo często sklepy stosują strategię trwających ciągle promocji, co może wyglądać źle wizerunkowo i uczyć konsumenta niekorzystnych biznesowo nawyków)
• pozwala elastyczniej zarządzać marżą: dzięki temu rozwiązaniu można personalizować rabaty per konkretny produkt, a nie na całą sekcję i w dodatku ograniczać jego wysokość nie tylko do maksymalnego, ustalonego wymiaru, ale do jak najbardziej kosztowo efektywnego względem pożądanego rezultatu
• czasowe okno udzielanego rabatu może zwiększać prawdopodobieństwo zrealizowania konwersji poprzez kompulsywny zakup i wykorzystanie zjawiska FoMO (ang. Fear of Missing Out)
• umożliwia kontrolować maksymalne progi rabatowe, dzięki czemu nie narusza to w żaden sposób ustalonej polityki cenowej i utrzymuje marżowość na oczekiwanym poziomie
• natywnie integruje się z formatami reklamowymi od Google, co wpływa na: a) sposób prezentowania ceny; b) ustalanie rabatów na podstawie realnych cen konkurentów w czasie rzeczywistym; c) bardziej przejrzysty sposób liczenia zwrotu w reklamach; d) w założeniu: finalny wzrost konwersji

Przykład z dokumentacji technicznej nt. sposobu prezentacji przykładowego rabatu załączam poniżej:

Jakie są wymagania do wdrożenia automatycznego rabatowania w Google Ads?

Wymagania są następujące:

• prawidłowy pomiar konwersji (z doświadczenia wiem, że najlepiej wdrożyć jednocześnie konwersje rozszerzone i asynchroniczną obsługę statusów płatności przez Google Tag Manager Server-Side)
• dodatkowe dane w feedzie produktowym dla konkretnych produktów:
  • parametr auto_pricing_min_price określający minimalną cenę po jakiej produkt ma być ofertowany
  • parametr cost_of_goods_sold na temat kosztu sprzedaży brutto oferowanego produktu (czyli inaczej: ile nas kosztuje produkt)
• konto Google Merchant Center na poziomie przynajmniej 1000 kliknięć produktów tygodnia
• zaimplementowanie systemu odbioru informacji od Google bazującego na tokenach JWT (ang. JSON Web Tokens) i informacjach zaszyfrowanych wraz z ładunkiem danych, a następnie wdrożenie obsługi systemu rabatów

Dodatkowo bardzo ważną kwestią jest dostosowanie się do przepisów prawa, w tym dyrektywy Omnibus.

Dyrektywa Omnibus ma na celu zapobieganie praktykom sztucznego podwyższania cen, by następnie sugerować fałszywe obniżki. Nowe regulacje zobowiązują sprzedawców do informowania klientów o najniższej cenie produktu lub usługi w ciągu ostatnich 30 dni przed wprowadzeniem zniżki. Cena i informacja o obniżce muszą być łatwo dostępne, mogą zostać umieszczone na produkcie, obok niego lub w jego pobliżu.

Choć sprzedawca może podać więcej cen odniesienia, informacje te powinny być jasne dla konsumenta. Na przykład przykład, obniżka może być przedstawiona jako: Cena promocyjna: 50 zł, Najniższa cena z ostatnich 30 dni: 75 zł (-33%), Cena regularna: 100 zł (-50%).

Ustawa uwzględnia pewne wyjątki, nie dotyczą one m.in.: produktów szybko psujących się, nieogłaszanych zmian cen, ogólnych oświadczeń marketingowych, ofert dostosowanych czy programów lojalnościowych.

Wdrażanie automatycznego rabatowania w Google Ads

Upewnij się na początku, że masz prawidłowo wdrożone konwersje. Upewnij się, że oprócz niezbędnych parametrów przesyłasz wartości opcjonalne, takie jak:

• identyfikator Google Merchant Center
• poziom zniżki

Jeśli tak, to wypełnij w Google Merchant Center dedykowany formularz, który umożliwia Ci akces do funkcjonalności automatycznego rabatowania. Dodatkowo sprawdź, czy Twój feed produktowy ma przykładową strukturę jak w załączeniu:

<item>
  <g:id>sku1234</g:id>
  <g:title>Koszula męska</g:title>
  <g:description>Stylowa koszula męska w kolorze niebieskim</g:description>
  <g:link>http://www.przykladowysklep.com/item1.html</g:link>
  <g:image_link>http://www.przykladowysklep.com/img/item1.jpg</g:image_link>
  <g:brand>MarkaX</g:brand>
  <g:google_product_category>Odzież &amp; Obuwie > Odzież męska</g:google_product_category>
  <g:product_type>Koszule męskie</g:product_type>
  <g:condition>nowy</g:condition>
  <g:availability>in stock</g:availability>
  <g:price>150 PLN</g:price>
  <g:auto_pricing_min_price>90 PLN</g:minimum_price>
  <g:cost_of_goods_sold>50 PLN</g:cost_of_goods>
  <g:gtin>00012345678903</g:gtin>
  <g:mpn>123456789</g:mpn>
</item>

Jeśli wszystko zgadza się, można przejść do następnego kroku - przetwarzania danych o rabacie promowanych przez Google.

Google na potrzeby tego rozwiązania przesyła dane poprzez dedykowany parametr linku URL we formacie Json Web Tokens (JWT). Przykładowy ładunek danych (payload) wygląda według dokumentacji następująco:

http://my.site.com/blacktee?pv2=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJjIjoiVVNEIiwiZXhwIjoxNTcxNjczNjAwLCJtIjoiMTQwMzAxNjQ2IiwibyI6InRkZHkxMjN1ayIsInAiOjIxLjk5fQ.Qlyr1dQ0vLUJx-iQKwkYE2uLHfYCLVEVGZkAq4fwGTSpMDQCbtzDJr5uGHG8dNKaKV5OlYDxLpW40tQVVe2gkQ

Taki payload jest zakodowany we formacie ES256, który można odkodować dzięki kluczowi publicznemu od Google. Treść po odkodowaniu wygląda następująco:

{
  "exp": 1571673600,
  "o": "tddy123uk",
  "m": "140301646",
  "p": 21.99,
  "c": "USD"
}

Payload zawiera następujące pola:

• exp - czas wygaśnięcia jako czas Unix. Jeżeli token wygasł, musi zostać odrzucony
• o - ID oferty, które może być użyte do sprawdzenia, czy strona docelowa (landing page) pasuje do produktu. Jeżeli wystąpi niezgodność, token musi zostać odrzucony
• m - ID sprzedawcy (merchant ID). Jeżeli ID sprzedawcy nie pasuje, token musi zostać odrzucony
• p - cena po obniżce
• c - waluta, zapisana dużymi literami

Oprócz tego są załączane informacje o samym sposobie szyfrowania:

{
  "alg": "ES256",
  "typ": "JWT"
}

Jeśli wszystko zgadza się, to istotne jest by po stronie sklepu zaimplementować mechanizm obsługujący dane od Google i nakładający stosowny rabat. Na koniec pozostaje proces akceptacji sklepu i testy mechanizmu.

Automatyczne rabaty Google Ads oferują unikalną i osobistą strategię cenową dla reklam internetowych e-commerce. Ale jak każda innowacyjna funkcjonalność, wymaga zarówno technicznego przygotowania, jak i zrozumienia zasad jej działania. Kluczowe etapy obejmują prawidłowe wdrożenie konwersji, posiadanie odpowiednio skonfigurowanego konta Google Merchant Center, dodanie specyficznych parametrów produktowych do feedu oraz wdorżenie systemu odbioru informacji od Google na bazie tokenów JWT.

Co więcej, we wszystkich tych procesach niezwykle ważne jest przestrzeganie dyrektywy Omnibus, która ma na celu uniknięcie fałszywych obniżek i zagwarantowanie przejrzystości dla konsumentów. W wyniku tych działań, dzięki technologii Google Ads, sklepy internetowe mogą oferować automatyczne, dynamiczne rabaty, które przyciągają klientów i osiągają lepsze rezultaty w sprzedaży.

Z postępującym rozwojem technologicznym w sektorze reklamy pojawiają się innowacyjne metody umożliwiające efektywniejsze ocenianie wyników działań marketingowych, jednocześnie respektujące wymagane przepisy. Podobną funkcję pełni Cloudflare Zaraz, będący odpowiednikiem popularnego Google Tag Manager Server-Side, oferującym zaawansowane możliwości w zakresie zarządzania i optymalizacji tagów reklamowych.

Co to jest Cloudflare Zaraz i ile kosztuje?

Cloudflare Zaraz to narzędzie od firmy Cloudflare (kupione przez nich w 2021 roku) stworzone do optymalizacji wydajności, bezpieczeństwa i prywatności stron internetowych poprzez zarządzanie narzędziami zewnętrznych integratorów.
Oto skrótowy opis jego kluczowych funkcji i zastosowań:

1. Zarządzanie narzędziami firm trzecich: Zaraz służy jako platforma do zarządzania różnymi narzędziami zewnętrznymi na stronie internetowej, takimi jak narzędzia analityczne, piksele reklamowe, chatboty i narzędzia automatyzacji marketingu. Na przykład, w przypadku narzędzi analitycznych, takich jak Google Analytics, Zaraz umożliwia ich ładowanie w chmurze, co może pomóc w zmniejszeniu obciążenia przeglądarki użytkownika i przyspieszyć działanie strony.
2. Optymalizacja szybkości, prywatności i bezpieczeństwa: Zaraz jest zaprojektowany z myślą o minimalizowaniu wpływu narzędzi zewnętrznych na wydajność strony. Ładując narzędzia w chmurze, redukuje to obciążenie przeglądarki użytkownika, co może przyczynić się do szybszej pracy strony.
3. Zarządzanie tagami: Narzędzie pozwala na zarządzanie tagami strony internetowej, co obejmuje sekwencjonowanie, monitorowanie i grupowanie tagów. Dla przykładu, sklep internetowy może używać Zaraz do zarządzania tagami śledzącymi konwersje, co pomaga w efektywniejszym śledzeniu działań marketingowych i optymalizacji reklam. Dodatkowo wspiera zarządzanie zgodami na uruchomienie konkretnych tagów i przechowuje dane zgodnie z wymogami GDPR.
4. Scentralizowany pulpit nawigacyjny: Zaraz oferuje jedno miejsce do zarządzania wszystkimi narzędziami stron trzecich. Ta centralizacja może ułatwić monitorowanie i kontrolowanie współpracy między narzędziami oraz ich wpływu na wydajność strony.

Ogromnym plusem tego narzędzia jest względnie niska cena: do 100 000 zapytań na stronie internetowej miesięcznie Cloudflare Zaraz jest za darmo. Następny pakiet zaczyna się od 5 USD netto miesięcznie za 200 000 zapytań, gdzie każde kolejne 1000 zapytań kosztuje 0,50 USD netto.

Warto również zaznaczyć, że funkcjonalność przeznaczona do odczytywania danych ze struktur danych załączonych na stronie internetowej wymaga płatnego pakietu. Zestawiając to jednak z innymi kosztami wdrożeń rozwiązań typu server-side, prezentuje to się bardzo korzystnie:

Google Tag Manager Server-Side — czym jest, jak działa i ile kosztuje?

Zmiany technologiczne na rynku reklamowym i idący za tym postęp dostarcza nowe rozwiązania służące lepszemu pomiarowi skuteczności kampanii reklamowych. Jednym z tych rozwiązań jest rozszerzenie znanego powszechnie narzędzia Google Tag Manager — Google Tag Manager Server-Side.

Kacper DurasKacper Duras

Jak działa Cloudflare Zaraz?

Cloudflare Zaraz działa w ramach infrastruktury firmy Cloudflare - jednego z największych dostawców usług chmurowych na świecie. Jej kluczowe usługi obejmują:

1. CDN (Content Delivery Network): Cloudflare posiada globalną sieć serwerów, które pomagają przyspieszyć ładowanie stron internetowych poprzez przechowywanie kopii treści stron w lokalizacjach bliższych użytkownikom.
2. Ochrona DDoS: Oferuje zaawansowaną ochronę przed atakami typu Distributed Denial of Service (DDoS), chroniąc strony internetowe przed nadmiernym ruchem, który może je unieruchomić.
3. Ochrona przed botami i bezpieczeństwo aplikacji internetowych: Zapewnia narzędzia do blokowania szkodliwych botów i automatycznych ataków, a także zabezpiecza aplikacje internetowe przed różnymi zagrożeniami.
4. Firewall aplikacji internetowej (WAF): Cloudflare oferuje WAF, który pomaga filtrować, monitorować i blokować szkodliwy ruch do aplikacji internetowych.
5. SSL/TLS: Usługi Cloudflare obejmują szyfrowanie SSL/TLS, co zwiększa bezpieczeństwo danych przesyłanych między serwerami a klientami.
6. DNS (Domain Name System): Oferuje szybkie i bezpieczne usługi DNS, które pomagają w przekształcaniu nazw domen na adresy IP.
7. Optymalizacja wydajności: Cloudflare oferuje różne narzędzia do optymalizacji wydajności stron internetowych, w tym kompresję, minifikację i inne.
8. Obsługa protokołu HTTP/3: Cloudflare wspiera najnowsze wersje protokołów internetowych, w tym HTTP/3, co przyczynia się do szybszego ładowania stron.

Te usługi są szczególnie ważne dla firm i organizacji, które chcą zabezpieczyć swoją obecność online oraz poprawić wydajność i dostępność swoich stron internetowych. Cloudflare jest znane z łatwości wdrożenia i szerokiego zakresu usług, co czyni je popularnym wyborem wśród wielu firm na całym świecie.

Dzięki efektowi synergii usług, korzystanie ze Zaraz wiąże się głównie ze standardowym procesem instalacji produktu firmy Cloudflare. Następnie, kody śledzące Cloudflare Zaraz załączają się w ramach chronionej strony internetowej i są gotowe do działania, oczywiście uprzednio wybierając plan usługi Zaraz.

W jaki sposób integrować usługi z Cloudflare Zaraz?

Na samym starcie Cloudflare proponuję kilkanaście gotowych już konfiguracji, dzięki którym możesz zintegrować się od ręki z większością komercyjnych narzędzi na rynku:

Oprócz tego istnieje możliwość wpięcia własnych kodów, zapytań HTTP, a ponadto producent umożliwia również stworzenie własnej integracji, tj. komponentu w języku TypeScript, dzięki czemu integracja z narzędziem trzecim może być znacznie prostsza.

Następnie, należy podążać za instrukcją konkretnego rozwiązania, a następnie wdrożyć kody śledzące. Istotną sprawą jest to, że strona na której funkcjonuje Zaraz musi działać za proxy Cloudflare, czyli bazową usługą firmy. Inaczej trzeba zrealizować dodatkowy krok, polegający na dodaniu subdomeny i odwołania do pliku JavaScript, który odpowiada za ładowanie skryptów.

Dalej, trzeba wdrożyć strukturę danych podobną jak w Google Tag Manager oraz zaimplementować system zarządzania zgodami plików cookies. Po tym kroku można zaobserwować, jak narzędzia analityczne zbierają dane zgodnie ze wszystkimi zasadami i specyfikacjami technicznymi.

Google Tag Manager jest istotnym, a czasem wręcz jednym z niezbędnych narzędzi do implementacji właściwego pomiaru zachowań użytkowników podczas uruchamiania i zarządzania kampaniami reklamowymi. Wersja rozwiązania typu server-side zapewnia dodatkowe możliwości w zakresie wdrożeń integracji, ale nie jest wolna od problemów — jednym z kluczowych zagadnień jest to, ile aplikacja kosztuje i w jaki sposób można ograniczyć koszty.

Jak można zainstalować Google Tag Manager Server-Side?

Więcej o zagadnieniu Google Tag Manager Server-Side napisałem w niniejszym wpisie:

Google Tag Manager Server-Side — czym jest, jak działa i ile kosztuje?

Zmiany technologiczne na rynku reklamowym i idący za tym postęp dostarcza nowe rozwiązania służące lepszemu pomiarowi skuteczności kampanii reklamowych. Jednym z tych rozwiązań jest rozszerzenie znanego powszechnie narzędzia Google Tag Manager — Google Tag Manager Server-Side.

Kacper DurasKacper Duras

W bardzo dużym, acz szczegółowym, skrócie:

• Google Tag Manager Server-Side jest zaprzeczeniem dotychczasowego, spopularyzowanego podejścia Google do płatności za ich usługi - o ile dotychczasowy model bazował na używaniu danych na potrzeby ekosystemu reklamowego tejże firmy, tak utrzymanie instancji Google Tag Managera Server-Side wymaga stosownych zasobów serwerowych
• domyślnie Google proponuje skorzystanie z Google Cloud Platform i ich instancji Cloud Run lub App Engine. Dostępne są w bezpłatnym wariancie pod wymogiem przestrzegania bardzo szczegółowych limitów. Jednocześnie, Google w dokumentacji technicznej proponuje przykładową, minimalną konfigurację ich rozwiązania, co ma kosztować ~90 USD netto miesięcznie. Tańsze rozwiązanie App Engine jest dostępne, acz preferowane jest korzystanie z droższego Cloud Run
• należy pamiętać, iż w ramach Google Cloud Platform można dokupić usługi dodatkowe, które nie są objęte powyższą estymacją (np. autoskalowanie zasobów) — są dodatkowo płatne, gdzie co prawda trudno przy podążaniu za instrukcją krok po kroku popełnić błąd (i np. pominąć notyfikację o przekroczeniu odpowiedniego progu finansowego), ale przy próbie wyjścia poza standardowy schemat, może być to bolesny finansowo błąd

Istnieje również trzeci sposób — samodzielna instalacja na własnym serwerze. Każdy sposób opisano w dokumentacji technicznej Google, lecz w mojej opinii przykład z implementacją na własnej infrastrukturze za pomocą Dockera wykonano lakonicznie, stąd skupię się na nim w tym wpisie.

Jednocześnie niezmiennie zalecam używanie Google Cloud Platform dla firm, które nie posiadają w swoich szeregach ludzi, którzy potrafią zarządzać samodzielnie serwerami VPS lub dedykowanymi. Google Cloud Platform co prawda jest dla osoby nietechnicznej skomplikowane, jednak znacznie mniej niż samodzielna instalacja. Istotne jest realne rozpoznanie potrzeb, zaproponowanie rozwiązania i wdrożenie — pamiętaj, że ryzykujesz niedostępnością usługi, a co za tym idziesz, możesz stracić pieniądze.

Czym jest Docker?

Docker to otwarte oprogramowanie umożliwiające automatyzację wdrażania, skalowania i zarządzania aplikacjami w kontenerach. Kontenery dockerowe są lekkie i przenośne, umożliwiające paczkowanie aplikacji wraz z wszystkimi ich zależnościami do standardowego formatu, który może być uruchomiony zarówno na lokalnym komputerze, jak i na zdalnych serwerach. Docker pozwala na oszczędność zasobów, ponieważ różne kontenery na tym samym systemie hosta współdzielą jądro systemu operacyjnego i używają programów już zainstalowanych na systemie hosta.

Architektura Docker składa się z Docker Engine, ekosytemu aplikacji i narzędzi oraz obrazów, kontenerów i plików Dockerfile. Docker Engine to serwer, który jest odpowiedzialny za tworzenie i zarządzanie kontenerami. Dockerfile to skrypt w języku Docker zawierający instrukcje, które pozwalają Docker Engine na budowanie obrazów kontenerów. Obrazy Docker to statyczne instantki plików, a kontenery Docker to te obrazy uruchomione w runtime.

Korzystanie z Dockera znacznie upraszcza procesy związane z rozwojem oprogramowania. Dzięki umiejętności tworzenia izolowanych środowisk dla aplikacji, Docker eliminuje problem pt. u mnie działa. To oznacza, że jeżeli aplikacja działa w kontenerze na jednym komputerze, powinna bez problemu działać na każdym innym komputerze, na którym jest uruchomiony Docker.

Docker ma wiele zalet w porównaniu do tradycyjnych maszyn wirtualnych (VM). Typowo, VM obsługiwaliby całe systemy operacyjne, które generowałyby duże obciążenia dla zasobów sprzętowych. Kontenery Docker na razie dzielą jądro systemu operacyjnego hosta i uruchamiają tylko procesy potrzebne do obsłużenia konkretnej aplikacji, co zasadniczo zmniejsza użycie zasobów.

Wreszcie, Docker stał się standardem w konteneryzacji i jest nieodłącznym elementem zarządzania architekturą serwerową. Docker integruje się z wieloma narzędziami do automatyzacji CI/CD (ang. continuous integration/continuous development), takimi jak Jenkins, GitLab i wiele innych. Jego rosnąca popularność i akceptacja wynika z możliwości usprawnienia procesów wytwarzania oprogramowania, poprawy bezpieczeństwa i ułatwienia wdrożeń. Bez względu na to, czy jest to mały projekt start-upu, czy duża korporacja, Docker pomaga organizacjom szybciej dostarczać oprogramowanie bez kompromisów co do jakości.

Proces instalacji

Na początku musisz wyposażyć się w serwer wirtualny. Blog który czytasz jest utrzymywany na serwerach firmy cyberFolks — korzystam z ich usług ze względu na sensowną jakość i bardzo dobre wsparcie. Zdecydowanie na potrzeby samego Google Tag Managera wystarczy pakiet vps_UP! (w mojej opinii do większości stron jak np. ten blog, czy mniejsze sklepy internetowe, jest to wystarczająca pojemność do instalacji aplikacji i cena ~50 PLN netto vs 90 USD netto prezentuje się znacznie korzystniej). Dla przykładu przeprowadzę proces na obrazie serwera Ubuntu 22.04.03 LTS (Jammy Selfish).

Wyznacz mysubdomenę, która będzie odnosiła się do Google Tag Manager Server-Side. Podłączmy pod nią rekord A, który będzie wskazywał na otrzymany adres IP.

Potem połączmy się ze serwerem za pomocą SSH. Po zalogowaniu wywołajmy dwa standardowe polecenia:

$ user@example-vps: apt-get update
$ user@example-vps: apt-get upgrade

Po aktualizacji zależności czas na zainstalowanie trzech aplikacji — Dockera, Nginxa i UFW:

$ user@example-vps: apt-get docker.io nginx ufw

NGINX to popularne oprogramowanie, które jest używany jako serwer HTTP (czyli do utrzymywania stron www), serwer proxy, serwer poczty i serwer proxy dla protokołów e-mail takich jak IMAP, POP3 i SMTP. Pierwszy raz został wydany w 2004 roku i od tego czasu zdobył ogromną popularność ze względu na swoją wydajność, stabilność, bogate funkcje, prostą konfigurację i niskie zużycie zasobów.

Działa na architekturze opartej na zdarzeniach, co oznacza, że zamiast tworzyć nowy proces lub wątek dla każdego nowego połączenia (co ma miejsce w tradycyjnych serwerach webowych, takich jak Apache), NGINX korzysta z niewielkiej, stałej liczby procesów lub wątków do obsługi wielu połączeń równocześnie. Ta architektura pozwala mu skalować się bardzo dobrze i zapewniać doskonałą wydajność, nawet przy dużej ilości ruchu.

NGINX może być używany jako serwer proxy. Ta konfiguracja jest używana do dystrybucji ruchu do wielu serwerów, do obsługi żądań statycznych, dynamicznych, strumieniowych lub realizacji cache dla szybszych odpowiedzi. Dzięki temu można ładować aplikacje webowe bez obciążania głównej aplikacji serwera. Daje to możliwość obsługi większych ilości ruchu i oferowania lepszej wydajności.

Właśnie NGINX jest potrzebny po to, by skorzystać z możliwości skonfigurowania jako serwer proxy. Obraz Dockera który później uruchomimy uruchamia swój serwer HTTP, acz dla bezpieczeństwa nie jest wskazane wystawianie aplikacji bezpośrednio w takiej formie.

Z kolei, UFW (Uncomplicated Firewall) to interfejs użytkownika dla zarządzania zaporą sieciową, zaprojektowany z myślą o prostocie i wygodzie użytkowania. UFW to narzędzie linii poleceń, które jest prekonfigurowane do potrzeb większości użytkowników, oferując jednocześnie możliwość zaawansowanej konfiguracji. UFW został stworzony dla systemu operacyjnego Ubuntu, ale działa na innych dystrybucjach Linuxa, które korzystają z iptables.

UFW pozwala na łatwe dodawanie i usuwanie reguł zapory sieciowej z interaktywnego i prostego w użyciu interfejsu. Użytkownicy mogą skonfigurować, które usługi mają być dostępne dla publicznego ruchu sieciowego, a które mają być zablokowane. Ten uproszczony interfejs ułatwia zarządzanie zaporą sieciową nawet dla początkujących użytkowników, chroniąc jednocześnie systemy przed nieautoryzowanym dostępem.

Skoro mamy instalację za sobą, skonfigurujmy zaporę:

$ user@example-vps: ufw allow 'Nginx Full'
$ user@example-vps: ufw allow 'OpenSSH'

Dzięki tym regułom będzie można zalogować się do serwera za pomocą SSH i otworzyć witrynę internetową.

Dalej, czas na uruchomienie Dockera:

$ user@example-vps: docker run -restart always -p 8080:8080 -e CONTAINER_CONFIG='<config string>' -e PREVIEW_SERVER_URL='<HTTPS preview server url>' gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

Rozkładając komendę na czynniki pierwsze:

• docker run - wywołanie polecenia run z pakietu pakietu docker
• -restart always - parametr always dla klucza restart powoduje, że instancja będzie automatycznie resetowała się wtedy, kiedy napotka błąd lub wyłączy się. Można ustawić to oczywiście w inny tryb, acz w przypadku Google Tag Manager Server-Side zależy nam, żeby działał cały czas. Uważam, że nie ma potrzeby innego ustawienia - dlaczego, wyjaśnię poniżej
• -p 8080:8080 - ustawienie portu, dla którego serwer HTTP naszego kontenera włączy się. Domyślnie każdy nasłuch jest realizowany na port 80 - tam działa już zainstalowany wcześniej NGINX
• gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable - wybór, który obraz powinien uruchomić się w kontenerze

Ostatnie dwa ustawienia omówię osobno, ponieważ jest to bardzo istotne dla zrozumienia charakteru działania aplikacji:

• -e CONTAINER_CONFIG='<config stream>'
• -e PREVIEW_SERVER_URL='<HTTPS preview server url>'

Najprościej będzie to wytłumaczyć w postaci wizualnej:

W istocie instalacja Google Tag Manager Server-Side sprowadza się do tego, iż uruchamiamy serwer pośredniczący zapytania pomiędzy klientem, a końcowym usługodawcą. Należy zaznaczyć, że cała konfiguracja leży dalej na serwerach Google. Zmienna CONTAINER_CONFIG służy wprowadzeniu unikalnego klucza konfiguracyjnego, który uzyskujesz przy tworzeniu Google Tag Managera Server-Side w sposób manualny.

PREVIEW_SERVER_URL jest ustawieniem serwera poglądowego. Wpisujesz tutaj subdomenę, na której Twój kontener ma być aktywny. Na przykład dla tej strony internetowej to jest analytics.kacperduras.pl.

Kolejno, skonfigurujemy NGINXa, tworząc plik konfiguracyjny w odpowiedniej lokalizacji:

$ user@example-vps: cd /etc/nginx/sites-available/
$ user@example-vps: touch google-tag-manager.conf
$ user@example-vps: nano google-tag-manager.conf

Poniżej załączam przykładową, minimalną konfigurację, która wystarczy do uruchomienia serwera proxy:

server {
  listen 80;
  listen [::]:80;

  server_name domain.com www.domain.com;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_pass http://127.0.0.1:8080;
  }
}

Dzięki temu każde zapytanie będzie przekierowane do aplikacji na porcie 8080 - w tym przypadku, naszego kontenera. Pamiętaj, żeby w miejscu domain.com wprowadzić subdomenę, na której ma działać kontener.

Przy okazji skonfigurujmy domyślny serwer HTTP:

$ user@example-vps: nano default

Na przykład w taki sposób:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  server_name _;

  location / {
    return 403;
  }
}

Dzięki temu, przy wpisaniu adresu IP serwera w przeglądarkę, wyświetli się błąd dotyczący braku dostępu do zawartości.

Zrestartujmy i sprawdźmy, czy konfiguracja załączyła się w porządku:

$ user@example-vps: sudo service nginx restart

Jeśli tak i nie pojawił się żaden błąd, pora na skonfigurowanie darmowego certyfikatu SSL od Let's Encrypt za pomocą aplikacji certbot:

$ user@example-vps: sudo apt-get install certbot python3-certbot-nginx
$ user@example-vps: sudo certbot --nginx -d example.com -d www.example.com
$ user@example-vps: sudo certbot renew --dry-run

W miejscu `example.com` wpiszmy domenę, kolejno wystarczy załączyć zaporę:

$ user@example-vps: sudo ufw enable

I wszystko gotowe. Jako test odpytajmy serwer, czy odpowiada. Na potrzeby poglądowe załączam link do mojego:

https://analytics.kacperduras.pl/healtz

Najpopularniejsze problemy i rozwiązania

Pytanie: Dlaczego Google zaleca minimum dwa kontenery, a Ty instalujesz tylko raz?
Odpowiedź: W znacznej ilości usług instalacji Google Tag Manager Server-Side którą dotychczas zrealizowałem wystarczył jeden serwer w standardowej konfiguracji. Google promuje podejście dywersyfikacji zasobów i rozkładania równomiernego obciążenia tak, by minimalizować ryzyko niedostępności usługi. Należy pamiętać, że usługa load balancingu jest dodatkowo płatna względem minimalnych estymacji założonych przez Google, a wraz ze wzrostem ilości zapytań potrzebnej do obsługi, będą też potrzebne większe instancje o lepszej specyfikacji.

Pytanie: Skorzystam z Twojej porady, w jaki sposób mam postępować, gdy wzrośnie ruch i co za tym idzie, ilość zapytań?
Odpowiedź: Na początek spróbuj zwiększyć konfigurację serwera, a następnie uruchomić równoległy obok i uruchomić dodatkowy, który będzie odpowiadał za pośredniczenie w rozdzielaniu ruchu. NGINX posiada wbudowaną funkcję load balancingu, polecam sprawdzić ją w praktyce. Z doświadczenia polecam również HaProxy. W ramach mojego blogu korzystam z usług firmy CloudFlare, która łączy kilkanaście usług w jedną, zwartą całość. Pamiętaj, że przy konfiguracji równoległych serwerów zadbaj, by komunikowały się w prywatnej sieci lub miały do siebie wyłącznie wzajemny dostęp, bez otwierania komunikacji na zewnątrz.

Pytanie: Jak potem nadzorować, czy wszystko działa w porządku?
Odpowiedź: Monitoruj aplikację, pomocne będzie tutaj Docker Engine API oraz usługi do monitorowania infrastruktury, np. Zabbix lub rozwiązania SaaS typu UptimeRobot.

Pytanie: Czy muszę to wdrażać?
Odpowiedź: W mojej opinii tak. Uzasadniłem to tutaj.

Pytanie: Wyskoczył mi błąd lub mam dodatkowe pytanie. Pomożesz mi?
Odpowiedź: Jasne, zapraszam do kontaktu.

Zmiany technologiczne na rynku reklamowym i idący za tym postęp dostarcza nowe rozwiązania służące lepszemu pomiarowi skuteczności kampanii reklamowych, przy jednoczesnym zachowaniu zgodności z niezbędnymi regulacjami. Jednym z tych rozwiązań jest rozszerzenie znanego powszechnie narzędzia Google Tag Manager — Google Tag Manager Server-Side.

Co to jest Google Tag Manager Server-Side?

Google Tag Manager Server-Side jest rozszerzeniem standardowego narzędzia firmy Google, jakim jest Google Tag Manager. Wersja server-side skupia się na przenoszeniu procesu przetwarzania tagów (inaczej: kodów śledzących i innych integracji z narzędziami) z przeglądarki użytkownika na serwer strony internetowej. W swoim założeniu, to rozwiązanie ma na celu zwiększenie prędkości ładowania strony, lepszą kontrolę danych i poprawę kompatybilności z blokerami reklam.

Podczas gdy oryginalny Google Tag Manager koncentruje się na zarządzaniu tagami po stronie klienta (tj. w przeglądarce użytkownika), Google Tag Manager Server-Side przenosi znaczną część tej pracy na serwer strony www. Przeniesienie przetwarzania tagów na serwer oznacza, że strona internetowa może być teoretycznie szybsza i mniej obciążona dla użytkownika. W przypadku Google Tag Managera po stronie klienta, każdy tag dodaje dodatkowy ciężar dla końcowego urządzenia użytkownika.

Google Tag Manager Server-Side oferuje również lepszą kontrolę nad przesyłanymi danymi. Oznacza to, że można dokładnie kontrolować, jakie informacje są przesyłane do serwisów trzecich, co pozwala na ochronę prywatności użytkownika i zgodność z przepisami o ochronie danych. W przeciwieństwie do tego, Google Tag Manager po stronie klienta przesyła dane bezpośrednio z przeglądarki do usług trzecich, co może w niektórych scenariuszach stwarzać potencjalne ryzyko naruszenia prywatności.

Inna korzyść Google Tag Manager Server-Side polega na tym, że jest mniej podatna na blokadę przez technologie anty-śledzenia i blokery reklam. Te narzędzia często działają, blokując skrypty uruchamiane w przeglądarce, co dotyczy standardowego Google Tag Manager. Wpływa to w szczególności na prawidłowość pomiaru danych do narzędzi służących kompleksowej analizie i ocenie skuteczności działań marketingowych. W przypadku wersji server-side, tagi są procesowane na serwerze zamiast w przeglądarce, co zwiększa prawdopodobieństwo ich prawidłowego działania.

Jak działa Google Tag Manager w wersji server-side?

Różnice w działaniu wersji Google Tag Manager najlepiej pokazać we formie wizualnych grafów.

Podstawową różnicą, jak wskazałem we wstępie, jest to, iż standardowa wersja Google Tag Manager przesyła informacje o wykonanych interakcjach na naszej stronie, za pomocą urządzeń końcowego klienta bezpośrednio do Google. Charakterystycznym problemem tego typu ścieżki jest to, iż można ładunek tego typu przechwycić i zablokować - taka sytuacja ma miejsce przy narzędziach do blokady reklam.

Rozszerzenie Google Tag Manager umożliwia ukrycie docelowego odbiorcy informacji, wskazując na naszą stronę internetową. Dzięki temu rozwiązaniu nie jest możliwe całkowite wyeliminowanie problemu ograniczeń śledzenia końcowych użytkowników, ale znaczne ograniczenie.

Częściowo charakterystykę utrudnień dotyczących zmian w prywatności cyfrowych tożsamości wytłumaczyłem w poniższym artykule:

Apple i system AppTrackingTransparency w praktyce

Wraz z aktualizacją do iOS 14, wprowadzono system AppTrackingTransparency, zapewniający odbiorcom urządzeń większą kontrolę nad udostępnianiem informacji.

Kacper DurasKacper Duras

Ile kosztuje wdrożenie Google Tag Manager Server-Side?

Koszty wdrożenia Google Tag Manager Server-Side potrafią być zróżnicowane, wynika to z trzech elementów.

Pierwszą składową jest to, gdzie utrzymywana jest aplikacja. Dotychczasowe, bezpłatne aplikacje od Google promowały bardzo wypłaszczone podejście związane z implementacją rozwiązań technologicznych i jednocześnie przenosiły szereg obowiązków z końcowych użytkowników, takich jak m.in. utrzymywanie infrastruktury technologicznej. Obecnie, Google zachęca do skorzystania z ich usług chmurowych pod szyldem Google Cloud Platform, który co prawda posiada, pod szczegółowymi warunkami, bezpłatny limit dla użytkowników nowych i korzystających ze zasobów w ograniczonym stopniu, ale z drugiej strony informuje później o realnych kosztach w przypadku ich przekroczenia i prezentuje przykładowe, najtańsze konfiguracje jako punkt odniesienia:

In this Cloud Run configuration, each server costs approximately $45 /month (USD). Each server is a Cloud Run instance with 1 vCPU and 0.5GB memory using the CPU always allocated pricing model.

We recommend running a minimum of 2 instances to reduce the risk of data loss in case of a server outage. However, you may choose to run fewer (or more) servers. We expect that autoscaling 2-10 servers will handle 35-350 requests per second, though the performance will vary with the number of tags, and what those tags do.

Źródło: klik

Zakładając rekomendacje Google, 90 USD netto miesięcznie za sam fakt korzystania z aplikacji, która umożliwia śledzenie zachowań odbiorców w Internecie, może być dla części przedsiębiorstw zbyt drogie. Oprócz tego, dochodzą problemy innej natury:

• autoskalowanie zasobów, którego dużym plusem jest dostosowywanie potrzebnej mocy obliczeniowej do obciążenia, w praktyce bez nałożenia limitów wydatków na usługi może spowodować bardzo wysoki rachunek
• kurs USD, który przy braku stosownego zabezpieczenia potrafi i wahaniach walutowych zwiększa koszty
• dodatkowe usługi, które włączone przypadkiem lub bez odpowiedniego doinformowania się potrafią powiększyć saldo o dodatkowe kwoty do uregulowania (np. sprawniejsze łącze internetowe, load balancing)

Można skorzystać z równoległego, odrobinę tańszego wdrożenia dla Google Cloud Platform App Engine, acz rekomendowanym rozwiązaniem jest użycie wyżej wymienionego Cloud Engine.

Tańszym, acz trudniejszym wdrożeniem jest zainstalowanie samodzielne instancji Google Tag Manager u siebie na serwerze — sama konfiguracja itd. pozostaje niezmiennie na serwerach Google i wymaga stałej komunikacji, ale część warstwy aplikacyjnej jest pod kontrolą na własnych zasobach, co umożliwia sprawniejsze zarządzanie kosztami i bezpieczeństwem wdrożenia.

Jak wdrożyć Google Tag Manager tanim kosztem?

Google Tag Manager jest istotnym, a czasem wręcz jednym z niezbędnych narzędzi do implementacji właściwego pomiaru zachowań użytkowników podczas uruchamiania i zarządzania kampaniami reklamowymi.

Kacper DurasKacper Duras

Jednocześnie niezmiennie zalecam używanie Google Cloud Platform dla firm, które nie posiadają w swoich szeregach ludzi, którzy potrafią zarządzać samodzielnie serwerami VPS lub dedykowanymi. Google Cloud Platform co prawda jest dla osoby nietechnicznej skomplikowane, jednak znacznie mniej niż samodzielna instalacja.

Jako alternatywę można zastosować usługi typu Stape.io, które znacznie taniej utrzymują instancje Google Tag Manager i uproszczają proces konfiguracji do minimum i posiadają przystępniejszy cennik, jednak też posiadają swoje ograniczenia funkcyjne oraz prędkość wsparcia kolejnego, dodatkowego podwykonawcy. Każde z rozwiązań posiada swoje plusy i minusy, gdzie całość rozchodzi się głównie o to, jaki składnik budżetu dopuszczamy na realizację wdrożenia i jego utrzymanie — dobrze przeprowadzone wdrożenie generuje minimalny nakład finansowy w postaci roboczogodzin administratora serwerem, z doświadczenia wiem, że bywa, iż praktycznie zerowy.

Drugim elementem finalnego kosztu wdrożenia jest przeniesienie dotychczasowej konfiguracji kodów śledzących i pokrewnych integracji na server-side. Wymaga to rozpoznania elementów, które można przenieść i przeprowadzenia całego procesu. Czas realizacji zależy od tego, jak dotychczasowe rozszerzenia działają i w jaki sposób są skonstruowane - bardzo często używanie Google Tag Manager, nawet w podstawowym wariancie, kłóci się chociażby z instalacją wtyczek na popularnych CMSach typu WordPress. Trzeba wtedy przenieść wszystkie kody śledzące, a dzięki Google Tag Manager Server-Side jest możliwa chociażby integracja z API Konwersji od Mety:

Co to jest Meta (Facebook) Conversions API?

API konwersji Facebooka (ang. Facebook Conversions API) to rozwiązanie do mierzenia interakcji użytkowników w ramach ekosystemu Facebooka. Dzięki niemu usługodawcy są w stanie połączyć swoje internetowe usługi z rozwiązaniami reklamowymi.

Kacper DurasKacper Duras

Ostatnią składową jest integracja ze stroną. Sam Google Tag Manager Server-Side w domyślnym wariancie działa jako bramka, która w pewnym sensie maskuje miejsce docelowego przesyłania danych, jednak wywołać konkretne tagi można za pomocą np. API. Kluczowe jest zagnieżdżenie kodów śledzących lub innych wywołań w miejscach dla nas istotnych. W większości znanych, popularnych przypadków wystarczy głównie integracja maski i kilku zdarzeń (najczęściej jednego) przesyłanych asynchronicznie, by całość działała poprawnie. Rezultatem jest minimalne obciążenie zasobów serwera z witryną internetową lub aplikacją.

Jak widzisz, wdrożenie Google Tag Manager Server-Side nie musi być skomplikowane, jeśli pozna się wszystkie szczegóły oraz metodologię liczenia kosztów wraz z możliwymi optymalizacjami.

Klientem jest firma tworząca materiały edukacyjne dla osób zainteresowanych zmianą zawodu lub wejściem na rynek pracy jako programiści.

Wyzwanie

W obliczu niestabilnej sytuacji ekonomicznej i ciężkiego roku związanego z pandemią COVID-19, możliwości finansowe konsumentów na wydatki wykraczające poza niezbędne funkcjonowanie są znacznie ograniczone. Jednocześnie wiele konsumentów chce zachować swój standard życia lub go znacznie podnieść, co wiąże się z ciągłym rozwojem i ponoszeniem kosztów edukacyjnych, np. zakupu materiałów lub szkoleń.

Klient przyszedł z następującym problemem:

• brak wiedzy na temat najczęstszych powodów rezygnowania z zakupu przez klientów
• duża cena produktu, a co za tym idzie, procent konwersji
• niewłaściwe integracje analityczne: firma realizująca platformę szkoleniową skonfigurowała narzędzia do reklam niepoprawnie, przez co pierwsze, samodzielne próby uruchomienia reklam przez mojego klienta były według niego nieskuteczne
• duża konkurencja na rynku szkoleń

Zbadanie grupy docelowej

Na początku przeanalizowałem uważnie produkt klienta, jego konstrukcję, komunikaty oraz grupę docelową. Następnie, zrealizowałem wywiady pogłębione, by sprawdzić:

• obawy odbiorców dot. produktu (dlaczego nie chcą kupić? do czego nie są przekonani?)
• ich oczekiwania względem materiałów szkoleniowych, możliwości dot. przyswajania treści
• możliwości ekonomiczne do zrealizowania transakcji

Wyniki były m.in. następujące:

• szkolenie konkuruje w tym samym segmencie, co tzw. bootcampy, czyli szkoły programowania, które mają niekoniecznie dobrą opinię - pod obietnicą gwarancji zatrudnienia sprzedaje się szkolenie, które niekoniecznie ma tyle samo wspólnego z rzeczywistością, co teoretycznie
• brak zaufania do marki/trenera - użytkownicy mają ograniczoną formę sprawdzenia wiarygodności szkoleniowca, a co za tym idzie, nie chcą przeznaczać dużych kwot na niesprawdzony program
• wysokość jednorazowej płatności dla większości badanych osób była za duża
• konieczność utrzymania się w aktualnej pracy powoduje ograniczony czas na przyswajanie wiedzy

Dostosowanie produktu

Po przeprowadzeniu analizy grupy docelowej i użyteczności względem niej produktu, wprowadzone zostały następujące zmiany:

• materiał podzielono na mniejsze części z większą ilością mniejszych prac domowych dla kursantów, co pozwoliło zwiększyć przyswajalność materiałów i satysfakcję z kursu
• usunięcie obietnic gwarancji zatrudnienia, a większe wyeksponowanie konkretnych, twardych kompetencji nabytych po realizacji materiałów
• płatność: wprowadzono system ratalny z możliwością rozłożenia płatności na aż 60 części, dzięki czemu na wydatek finansowy może pozwolić sobie znacznie więcej osób
• wprowadzenie obietnicy satysfakcji: zwrot pieniędzy do 30 dni bez podania powodu
• dodanie modułu skupiającego się wyłącznie na poszukiwaniu pracy i dobrego zaprezentowaniu się na rozmowach rekrutacyjnych
• wyraźniejsze zaprezentowanie opinii dotychczasowych, pozytywnych kursantów i ich historii, które zostały odmienione przez produkt
• wprowadzono materiały pośrednie o znacznie niższej wartości, które zwracały jednocześnie koszt reklamy

Konfiguracja analityki i ścieżek sprzedażowych

W ramach analityki zrealizowałem integrację Google Tag Manger typu server-side (dzięki czemu zwiększyłem dokładność śledzenia i ominąłem problemy związane z tzw. plikami cookies: kliknij tutaj) i zadbałem o zgodność śledzenia zgodnie z przepisami RODO (konieczność egzekwowania zgody na śledzenie reklamowe).

Następnie, oprócz konfiguracji filtrów do łatwiejszej analizy informacji, celi do mierzenia kluczowych interakcji dla klienta i realizacji punktów na ścieżce zakupowej, zadbałem o:

• prawidłowe wdrożenie mechanizmu User ID, dzięki czemu możliwe staje się później analizowanie LTV (ang. long-term value) klienta i poziomu jego lojalizacji (co jest kluczowe przy wieloetapowej ścieżce)
• przesyłanie danych o odbiorcach na bieżąco do rozwiązań reklamowych, dzięki czemu możemy odróżniać bezproblemowo użytkowników nowych, od powracających

Dalej, wraz z rozbudowaniem oferty produktowej przygotowałem ścieżki klienta - strony lądowania z odpowiednią zawartością, skonfigurowałem system do automatyzacji marketingu (w tym komunikacji e-mailowej), dbania o poziom retencji klientów, zbierania i analizowania feedbacku itd.

Dzięki temu klient dostał sprawny zestaw, który po uruchomieniu dostarczał konkretne dane biznesowe i nastawiony został na analizę długotrwałej relacji z końcowym konsumentem. Dodatkowo zostały stworzone powiadomienia na potencjalne, niepokojące wydarzenia i wdrożono pomiar nieprawidłowości funkcjonowania sklepu po stronie klienta (np. błędy w kodach JavaScript).

Kampania Facebook

Po skonfigurowaniu śledzenia reklamowego, analityki i dostosowaniu produktu, kampania reklamowa objęła następującą konstrukcję:

• pierwsza ścieżka klienta prowadziła poprzez produkty pośrednie do produktu końcowego poprzez e-mail marketing
• druga skupiała się na promowaniu webinaru, na którym sprzedawano finalny produkt

W każdym z wariantów zastosowano następujące rozwiązania:

• dedykowane kreacje video z historiami kursantów i pozytywnymi opiniami
• materiały odpowiadające na najczęstsze wątpliwości grupy docelowej
• przypomnienia o kończących się rabatach/możliwościach zakupu produktu, promowanie systemu ratalnego jako domyślnego w płatności
• chat i komunikację mejlową w celu zadbania o jak najlepsze wrażenia klienta przed zakupem produktu

Wyniki

Dzięki umiejętnie zaplanowanym działaniom i sprawnej reakcji na otaczające zjawiska, udało się:

• wygenerować 1,5 mln PLN przychodu przy budżecie mediowym wynoszącym prawie 100 000 PLN
• zwiększenie % konwersji do satysfakcjonującego poziomu, poprawienie wyników w postaci większego zasięgu klientów
• zadbać o wysoki poziom konwersji w ścieżce sprzedażowej (m.in. poprzez wdrożenie marketing automation i umiejętnym zaprogramowaniu oraz testowaniu scenariuszy)
• w wynikach ankiet: poprawić wrażenia z wykonania produktu, jego jakości i przydatności w realizacji celów przez klientów

Klientem jest firma zajmująca się sprzedażą asortymentu budowlanego, remontowego i ogrodniczego. Dotychczas firma nie miała dużego doświadczenia w segmencie e-commerce i całą sprzedaż opierała o lokalny punkt sprzedaży i kontrakty B2B.

Wyzwanie

Firma chciała uruchomić się na ogólnopolską sprzedaż i dostosowała pod to logistykę obsługi zamówień. Wykonała profesjonalny sklep internetowy na platformie Shoper Premium zgodny z najlepszymi praktykami pod kątem UI/UX, lecz niestety nie ma doświadczenia w prowadzeniu płatnych działań reklamowych.

Największymi problemami po przeanalizowaniu całej sytuacji jest:

• sezonowość asortymentu: branża budowlana jest bardzo podatna na zewnętrzne czynniki, co rzutuje na częstotliwość wydatków reklamowych niezbędnych do realizacji celu
• brak danych: dotychczas firma nie prowadziła działań reklamowych w Internecie
• niewłaściwe integracje analityczne: firma realizująca sklep skonfigurowała narzędzia do reklam niepoprawnie, przez co pierwsze, samodzielne próby uruchomienia reklam przez mojego klienta były nieskuteczne
• duża konkurencja: znaczną część produktów indeksowała się wraz z branżowym konkurentem, który prowadził w czasie startu agresywne kampanie reklamowe (w tym wizerunkowe)
• nierozpoznawalność marki: sklep jest nowy, stąd brakuje opinii i wiarygodności w Internecie o działalności

Konfiguracja analityki

Pierwszym krokiem jaki zrealizowałem było skonfigurowanie poprawnie śledzenia interakcji użytkowników. W tym celu zrealizowałem, niezależnie od platformy Shoper, integrację Google Tag Manger typu server-side (dzięki czemu zwiększyłem dokładność śledzenia i ominąłem problemy związane z tzw. plikami cookies: kliknij tutaj) i zadbałem o zgodność śledzenia zgodnie z przepisami RODO (konieczność egzekwowania zgody na śledzenie reklamowe).

Następnie, oprócz konfiguracji filtrów do łatwiejszej analizy informacji, celi do mierzenia kluczowych interakcji dla klienta i realizacji punktów na ścieżce zakupowej, zadbałem o:

• prawidłowe wdrożenie mechanizmu User ID, dzięki czemu możliwe staje się później analizowanie LTV (ang. long-term value) klienta i poziomu jego lojalizacji
• integrację CRMu klienta z Google Analytics do tworzenia zestawień poziomu wydatków do sprzedaży, na podstawie danych o marżach ze systemu, dzięki czemu skupialiśmy się na produktach, który dają realny dochód
• przesyłanie danych o odbiorcach na bieżąco do rozwiązań reklamowych, dzięki czemu możemy odróżniać bezproblemowo użytkowników nowych, od powracających

Dzięki temu klient dostał sprawny zestaw, który po uruchomieniu dostarczał konkretne dane biznesowe i nastawiony został na analizę długotrwałej relacji z końcowym konsumentem. Dodatkowo zostały stworzone powiadomienia na potencjalne, niepokojące wydarzenia i wdrożono pomiar nieprawidłowości funkcjonowania sklepu po stronie klienta (np. błędy w kodach JavaScript).

Kampanie Google Ads

Po skonfigurowaniu śledzenia reklamowego i narzędzi analitycznych uruchomiliśmy kampanie produktowe (a później Performance Max). W ramach tej części działań:

• zaimplementowałem mierzenie Opinii konsumenckich, dzięki czemu sklep po każdej transakcji zdobywa opinie natychmiastowo widoczne w Google i buduje swoją wiarygodność
• skorzystaliśmy w tzw. zewnętrznej porównywarki cenowej, dzięki czemu prowizja 20% nakładana do reklam przez Google stała się dla nas neutralna i więcej środków przeznaczaliśmy na agresywniejsze działania
• zadbałem o jakościowe informacje o produktach, uzupełniając wszystkie możliwe dane o asortymencie i testując różne warianty prezentowania danych (m.in. porównywałem tytuły, opisy, słowa kluczowe i zdjęcia)
• skonfigurowałem wszystkie zasoby wymagane przez kampanie, łącznie z dedykowanymi materiałami video dostarczonymi przez klienta
• stworzyłem podział produktów w kampaniach według dotychczasowego podziału kategorii w sklepie, celem wybadania potencjału poszczególnych segmentów

Realizacja optymalizacji

Kolejnym etapem pozostała realizacja optymalizacji - tutaj zastosowałem następujące rozwiązania:

• po zebraniu danych o najlepszych produktach i ocenie na podstawie danych historycznych ze sprzedaży stacjonarnej - z klientem wybraliśmy asortyment o przeznaczeniu całorocznym, wydzieliliśmy z klientem ofertę do osobnej kampanii, która została skonfigurowana w celu skupiania się nad pozyskiwaniem nowego konsumenta
• wykluczyliśmy z kampanii produktowych produkty o małym obrocie i niskim poziomie marży. Stworzyłem na nie dedykowaną kampanię remarketingową, skupiając się na tzw. wspomaganiu realizacji konwersji, tj. zakupu
• w celu zrównoważenia problemu związanego z sezonowością asortymentu, produkty niestabilne (tj. takie, których sprzedaż różni się drastycznie od dnia i jest powiązana np. z pogodą) wydzieliłem do osobnych kampanii i wdrożyłem oznaczenia specjalną etykietą w celu realizowania pod nie osobnej strategii
• pozostałe produkty podzieliłem na węższe kategorie i skonfigurowałem pod realizację celów kwartalnych
• stworzyłem kampanię na wyszukiwarkę pod odbiorców z naszej strony internetowej, dzięki której ratujemy przed realizacją transakcji u konkurencji

Następnie zaczęliśmy dbać o lojalizowanie klienta, m.in. poprzez cykliczny newsletter, precyzyjne kampanie SMS (dzięki marketing automation), czyli stopniowo zwiększać LTV bez udziału płatnych kampanii reklamowych.

Wyniki

Dzięki umiejętnie zaplanowanym działaniom i sprawnej reakcji na otaczające zjawiska, udało się:

• po pierwszym miesiącu zapewnić solidny w odczuciu klienta poziom rentowności z kampanii reklamowych, generując łącznie ponad 1 mln PLN obrotu
• obniżyć koszt powracającego klienta i oddzielić rodzaj płatnych reklam pod nowych, jak i lojalnych klientów
• zadbać o wysoki poziom konwersji w ścieżce sprzedażowej (m.in. poprzez wdrożenie marketing automation i umiejętnym zaprogramowaniu oraz testowaniu scenariuszy)
• skupić się na rentowności w momentach spadku sprzedaży, a w okresie nagłego wzrostu na maksymalnym wykorzystaniu potencjału ruchu i intensywnym zwiększaniu obecności w wyszukiwarce Google
• zapewnić solidne podstawy pod uruchomienie innych rozwiązań reklamowych, m.in. Bing Ads i Meta (Facebook) Ads

System operacyjny firmy Apple iOS (dawniej: iPhone OS) to dedykowane rozwiązanie dla urządzeń produkcji tej samej firmy. Oprogramowanie powstałe w 2007 przetrwało do dnia dzisiejszego i doczekało się aktualizacji do wersji oznaczonej numerem 14. Aktualizacja wprowadziła nową rzeczywistość dla świata digital marketingu, w której słowa "dane" i "prywatność" odmieniane są przez wszystkie przypadki, a gdzie rolę główną odgrywa nie tylko iOS, ale także cały ekosystem firmy Apple (m.in. iPadOS i tvOS).

1. Co to jest AppTrackingTransparency?
2. Znaczenie AppTrackingTransparency
3. Jak wdrożyć AppTrackingTransparency?
4. Podejście platform reklamowych

Co to jest AppTrackingTransparency?

Wraz z aktualizacją oprogramowania do iOS 14, firma Apple wprowadziła nowy system AppTrackingTransparency, zapewniający odbiorcom urządzeń większą kontrolę nad udostępnianiem informacji. AppTrackingTransparency to standard śledzenia danych dla urządzeń Apple, gwarantujący nadzór nad udostępnianiem szczegółów odbiorców podmiotom trzecim.

AppTrackingTransparency narzuca dla twórców aplikacji pod system Apple tworzenie przejrzystych informacji odnośnie zbieranych danych, jak i definiuje sposób przesyłania danych dla celów reklamowych (włączając w to funkcję statystyczną, kreacyjną itd.), zmieniając doświadczenia odbiorców z końcowym oprogramowaniem. Przykładem nowego nawyku dla użytkowników aplikacji mogą być eksponowane powiadomienia, związane z udzieleniem uprawnień na śledzenie interakcji.

Znaczenie AppTrackingTransparency

Wprowadzenie przez Apple standardu AppTrackingTransparency zmienia perspektywę postrzegania rozwiązań reklamowych. Dotychczasowe rozwiązania bazowały na integracjach firm trzecich (np. Google, Facebook), które bezpośrednio zbierały dane i przetwarzały na swoje wewnętrzne potrzeby. Od czasu wprowadzenia, Apple stawia siebie jako pośrednika w obrocie informacjami: od niego zależy jakie informacje udostępni dalej (i czy w ogóle to zrobi) i kiedy (albowiem w ramach nowego protokołu, wymiar czasowy kolportażu informacji może być ograniczony).

Z jednej strony, podejście Apple jest prokonsumenckie i stanowi element większej strategii, którą można podsumować hasłem reklamowym Privacy. That's iPhone. Działania cyfrowego giganta od dłuższego czasu zmierzają ku jeszcze większego zamknięciu się na zewnętrzne rozwiązania firm konkurencyjnych (np. limitując żywotność plików cookies w przeglądarce Safari). Na szczególną uwagę zasługują tutaj działania lobbingowe Facebooka, mające na celu powstrzymanie wprowadzanych zmian.

Druga strona medalu pozwala poddać pod wątpliwość zasadność idei Apple ws. prywatności. Najczęstsza podnoszona w debacie publicznej argumentacja:

• Apple poprzez ograniczanie personalizacji reklam obniża wartość danych odbiorców, a co za tym idzie: ich końcowe doświadczenia ws. preferencji reklam
• Reklamodawcy w przyszłości będą mieć problemy z efektywnym mierzeniem efektów działań
• Sieci reklamowe przestaną segmentować odbiorców do konkretnych podgrup, przez co działania na małych budżetach przestaną się opłacać
• Koszta związane z modyfikacją obecnych aplikacji i ich bieżącą obsługą staną się droższe

Najważniejszym jednak punktem sporu jest poziom uprawnień Apple, który dalej ma swobodny dostęp o informacji o swoich użytkownikach i może nimi dysponować w niezmienny względem stanu poprzedniego sposób.

Jak wdrożyć AppTrackingTransparency?

Apple na potrzeby implementacji AppTrackingTransparency udostępnił SKAdNetwork, czyli dedykowane API pod działania mające na celu śledzenie informacji o odbiorcach. Cały protokół można podzielić na trzy nisze:

• nisza dla właścicieli systemów reklamowych
• nisza dla programistów
• nisza dla reklamodawców

Schemat działania całego rozwiązania jest następujący:

Właściciele systemów reklamowych

Twórcy sieci reklamowych mają obowiązek być zarejestrowani w ramach specjalnego rejestru. Administratorzy rozwiązań marketingowych są odpowiedzialni za komunikację z Apple i autoryzowaniem źródeł pochodzenia określonych konwersji. Jednocześnie, mają za zadanie obsługiwać na bieżąco podmioty, chcące skorzystać z reklam dla systemów Apple w ramach poszczególnego systemu. Weryfikacja odbywa się poprzez sygnowanie zapytań dedykowanymi kluczami.

Programiści

Programiści przy projektowaniu aplikacji mają za zadanie dostosowania ścieżek odbiorców w taki sposób, by program w przewidywalny dla odbiorcy sposób wysyłał informacje o zbieraniu danych. Ponadto, muszą załączyć w kodzie źródłowym odpowiednie funkcje definiujące moment załączenia nasłuchu informacji (i użytkownika, który jest przypisany do specjalnego, identyfikacyjnego klucza), jak i chwilę realizacji konwersji.

Reklamodawcy

Reklamodawcy w tym wszystkim mają najprostsze zadanie - muszą sprawdzić, czy faktycznie aplikacja zgłasza wszystkie zdarzenia. Warto tutaj zaznaczyć, iż cały system może opóźniać raportowanie zdarzeń (poprzez uruchomienie timera, który sprawdza po pewnym czasie dane), przez co wyniki w kampaniach mogą być zaburzone (w abstrakcyjnych przypadkach: aż 3 dni).

Podejście platform reklamowych

Sieci reklamowe takie jak Facebook, czy Google, udostępniają własne integracje, spięte z ich ekosystemami reklamowymi. Pomimo jednak wyciągnięcia pomocnej dłoni dla programistów, ograniczają pole dla reklamodawców. Przykładem może być podejście Facebooka, który:

• narzuca wydzielenie zestawów reklamowych promujących aplikacje iOS do osobnych kampanii (i ogranicza ich ilość)
• likwiduje model atrybucji mający 28 dni (zmiana wprowadzona ze znacznym wyprzedzeniem) i ogranicza maksymalny czas trwania na 7 dni
• ogranicza ilość zdarzeń w Facebook Pixel do 8 rodzajów (i jednocześnie zaleca stosowanie głównie zdarzeń standardowych)
• usuwa segmentacje dla kampanii iOS względem danych demograficznych (wiek, lokalizacja itd.)

Z kolei Google postawiło na działania bardziej spokojne, wprowadzając swoje modyfikacje, m.in. w ramach usługi Google AdMob (emitenta reklam dla aplikacji mobilnych). Następnie, TikTok w ramach swojego systemu zliczania atrybucji z reklam polega na zewnętrznych partnerach, przez co integracje z ich systemem reklamowym nie zależą bezpośrednio od nich. Z kolei Pinterest i LinkedIn na chwilę pisania artykułu, nie opublikowali żadnych większych zmian w tym zakresie.

AppTrackingTransparency jest rewolucją dla branży digital marketingu: jaki ono wywrze faktyczny wpływ na otaczający nas świat, czas zweryfikuję. Nie mniej, konieczność i czas narzucają dostosowanie się do zmian, a na to warto być zawsze przygotowanym.

API konwersji offline (ang. Offline Conversions API) to rozwiązanie ułatwiające mierzenie fizycznych interakcji odbiorców i łączenie ze zdarzeniami zrealizowanymi cyfrowo. Integracja tego typu pozwala przy odpowiednim pokryciu ścieżki zakupowej klienta, śledzić skuteczność działań, których końcowe wskaźniki efektywności mogą być zrealizowane na wiele różnych sposobów. Co więcej, załączenie Offline Conversions API umożliwia dokładniejsze segmentowanie docelowej audiencji i dotarcie do nich ponownie, poprzez sieć reklamową Facebook.

Zastosowania Offline Conversions API

Meta (Facebook) Offline Conversions API jest rozwiązaniem serwerowym (ang. server-side), przeznaczonym do przesyłania większych ilości danych o odbiorcach korzystających z naszych usług poza standardową, internetową ścieżką. Jest to narzędzie komplementarne do analityki internetowej, jaką oferuję nam Meta (Facebook) Pixel i Meta (Facebook) Conversions API.

API konwersji offline idealnie sprawdzi się w połączeniu z mierzeniem takich interakcji jak:

• zakup przy kasie (z użyciem np. karty lojalnościowej lub innej metody płatności, która umożliwia identyfikację)
• zamówienia telefoniczne
• inne czynności, realizowane poza kanałem online

Jest to o tyle szczególnie istotne, iż zachowania użytkowników podlegają ciągłej ewolucji. Gwarantem zachowania jakości danych, a co za tym idzie, analiz i podejmowanych na podstawie nich decyzji, jest ścisła kontrola przepływu informacji, jakie pozostawiają odbiorcy i sposób ich grupowania.

Wady Offline Conversions API

Interfejs programistyczny Mety (Facebooka) pozwala dotrzeć do wielu segmentów odbiorców (w tym kompletnie nowych), jak i jednocześnie dostarcza bardziej szczegółowe informacje dot. aktualnej audiencji. Wiąże się to jednak z pewnymi utrudnieniami, które pokrótce opisałem w moim wpisie dotyczącego Meta (Facebook) Conversions API, a które ponownie przytoczę poniżej:

• wymagana wiedza programistyczna: załączenie tego rozwiązania jest niemożliwe bez posiadania specjalistycznej wiedzy. Mimo obecności już gotowych rozwiązań na rynku dochodzi szereg problemów na etapie serwisowania oprogramowania (m.in. elastyczność podpięcia, aktualizacje itd.). Działania tego typu wymagają przeznaczenia odpowiednich zasobów (finansowych i/lub czasowych)
• problem ze skalowaniem: popularne narzędzie Meta (Facebook) Pixel wysyła informacje po stronie klienta (ang. client-side) — jedynym obowiązkiem osób dokonujących integracji, jest zainstalowanie odpowiedniego skryptu śledzącego i oznaczenie miejsc raportowania (szczegółowo opisałem to tutaj). Przy Offline Conversions API, bardzo ważne jest uwzględnienie obciążenia przy zbieraniu i przesyłaniu informacji do Facebooka, jak i tak samo źródła, które różnią się w zależności od obranej logiki biznesowej (np. kasowniki, CRMy)
• szczegółowa analiza ścieżek klienta: samo wysyłanie informacji nic nie daje, jeśli nie wyznaczy się obiegu odbiorcy w ramach oferowanej usługi. Wymaganą potrzebą w ramach Meta (Facebook) Offline Conversions API jest identyfikacja użytkowników i dopasowywanie interakcji do ich zbiorczego profilu: w tym celu konieczne jest wyznaczenie ścieżek klienta, które zwiększą prawdopodobieństwo ujawnienia się (np. sklepy Biedronka i podanie numeru telefonu w celu naliczenia punktów za zakupy, marka Douglas i system kart lojalnościowych itd.)

Zapewniam jednak, iż warto pokonać wyżej wymienione trudności i zacząć działać już dziś: zmiany w zakresie przepływu danych następują szybko.

Jak działa Meta (Facebook) Offline Conversions API?

Istotnym faktem, związanym z projektowaniem integracji w ramach Offline Conversions API, jest czas wysyłki konwersji do systemów. Według dokumentacji wynosi on 90 dni od pierwszego punktu styku z usługą i jest liczony od momentu granicy realizacji docelowej interakcji, wyłączając czas, w którym użytkownik mógł zrealizować końcową akcję, w ramach określonego modelu atrybucji. Co to znaczy?

Najprościej to będzie opisać na przykładzie:

• załóżmy, że usługę X, która sprzedaje produkty Y. Jako czas atrybucji (czyli mówiąc w uproszczeniu, dopasowania do źródła reklamy) określamy 7 dni po kliknięciu kreacji reklamowej lub 1 dzień po jej wyświetleniu (niezależnie od tego, czy ją pominął). Jest to od 2020 roku maksymalne okno konwersji, jakie reklamodawcy są w stanie określić. Jednocześnie, tą decyzją uśredniamy granicę czasową ścieżki klienta do zdefiniowanych wartości (i to się analogicznie tyczy pozostałych wymiarów czasowych)
• użytkownik realizuje warunek przypisania do określonej atrybucji (klika w reklamę) i dodaje produkt do koszyka. Z jakiegoś powodu porzuca koszyk, ale zakłada konto w ramach usługi, dzięki czemu jego wybór zostaje zapamiętany i staje się możliwy to znalezienia
• konsument udaje się do fizycznej placówki należącej do firmy X i kupuje produkt fizycznie za gotówkę

Jako iż czas na realizacje konwersji w ramach obranych wymiarów wyniósł 7 dni, od wartości 90 dni odejmujemy ww. zakres i pozostaje 83 dni: tyle czasu pozostaje na wysłanie konwersji do Meta (Facebook) Offline Conversions API. Zalecam jednak, by robić to niezwłocznie. Praktyka często pokazuje, iż warto mieć aktualne dane przy interpretacji wyników, gdzie często wprowadzane zmiany są na żywo, co jest spowodowane m.in. wahaniem się stawek aukcji w systemach reklamowych.

Struktura zapytania

Struktura docelowego zapytania składa się z tablicy o nazwie data, która zawiera następujące obiekty w formacie JSON (których limit na jedno zapytanie wynosi 2000):

{ 
  match_keys: {"phone": ["HASH1","HASH2"], "email": ["HASH3","HASH4"]}, 
  currency: "USD", 
  value: 16,
  event_name: "Purchase",
  event_time: 1456870902,
  contents: [
    {id: "A", quantity: 1},
    {id: "B", quantity: 2},
    {id: "C", quantity: 1}
  ],
  custom_data: {
    event_source: "in_store"
  },
}

Należy tutaj wyszczególnić następujące, wymagane informacje:

• match_keys, czyli informacje kluczowe, po których można dopasować konwersję do odbiorcy (lista możliwych kombinacji znajduje się tutaj)
• event_time, czyli czas, kiedy zostało zrealizowane zdarzenie (co nie musi pokrywać się z momentem wysyłki)
• event_name, czyli nazwa zdarzenia

Z istotniejszych pól wyróżnię custom_data (miejsce na wysyłkę własnych danych, które mogą później służyć jako podstawa do zaawansowanej segmentacji). Pozostałe struktury są przesyłane zgodnie ze specyfikacją dla danego zdarzenia (jw. na przykładzie, dla Purchase). Lista możliwych zdarzeń znajduje się tutaj, a opis pozostałych pól funkcjonuje pod tym linkiem.

Wysyłka informacji

Przesyłanie danych o konwersjach offline odbywa się poprzez wysłanie zapytania typu POST na następujący URL:

https://graph.facebook.com/v9.0/<OFFLINE_EVENT_SET_ID>/events

Poniżej załączam przykład dla pakietu curl:

curl -X POST \
  -F 'data=[
       { 
         match_keys: {"phone": ["HASH1","HASH2"], "email": ["HASH3","HASH4"]}, 
         currency: "USD", 
         value: 16,
         event_name: "Purchase",
         event_time: 1456870902,
         contents: [
           {id: "A", quantity: 1},
           {id: "B", quantity: 2},
           {id: "C", quantity: 1}
         ],
         custom_data: {
           event_source: "in_store"
         },
       }
     ]' \
  -F 'access_token=<ACCESS_TOKEN>' \
  -F 'upload_tag=<UPLOAD_TAG>' \
  https://graph.facebook.com/v9.0/<PIXEL_ID>/events

Do każdego zapytania należy dołączać parametry access_token z kluczem dostępu do docelowego kontenera z konwersjami offline i upload_tag, który oznacza rodzaj lub źródło przesyłanych danych.

Token dostępu

Uzyskanie tokenu dostępu do wysyłki zapytań wiąże się ze stworzeniem specjalnej aplikacji w ramach ekosystemu Mety (Facebooka), która będzie określała poziom uprawnień dla końcowych odbiorców, którzy wysyłają informacje o konwersjach offline. Aplikacja w ramach protokołu OAuth2 potrzebuje dostępu do zasobów ads_management.

Obsługa błędów

Po wysłaniu zapytania do Meta (Facebook) Offline Conversions API, w odpowiedzi zostanie zwrócone pole num_processed_entries z liczbą prawidłowo przetworzonych zdarzeń. Jeśli wartości nie będą zgadzały się z tymi, które zostały przesłane, zostanie załączony błąd z dokładnym opisem.

Meta (Facebook) Offline Conversions API to inny standard przesyłania danych, jednak jak możesz zauważyć — bardzo wartościowy i nadający nowe znaczenie analityce działań z kanału dystrybucji treści, jakim jest Facebook i który umożliwia docieranie do nowych segmentów odbiorców.

API konwersji Mety (Facebooka) (ang. Meta (Facebook) Conversions API) to rozwiązanie do mierzenia interakcji użytkowników w ramach ekosystemu Mety (Facebooka). Dzięki niemu usługodawcy są w stanie połączyć swoje internetowe usługi z rozwiązaniami reklamowymi, niezależnie od ustawień prywatności urządzeń końcowych odbiorców i przesyłać bardziej szczegółowe dane. Meta (Facebook) Conversions API umożliwia stworzenie jakościowych podstaw pod szczegółową analitykę konsumentów na całym etapie lejka sprzedażowego.

Zastosowania Meta (Facebook) Conversions API

Meta (Facebook) Conversions API jest rozwiązaniem serwerowym (ang. server-side), przeznaczonym do przesyłania większych ilości danych o odbiorcach korzystających z naszych usług. W przeciwieństwie do innego narzędzia nazywającym się (Meta) Facebook Pixel, API konwersji Mety (Facebooka) działa niezależnie od urządzeń odbiorców. Co to oznacza? Mianowicie:

• mierzenie danych jest ograniczone głównie konstrukcją usługi: klienci nie mają świadomości o tym, iż są obserwowani przez narzędzia analityczne
• odbiorcy nie są w stanie zablokować integracji: jest to bardzo ważne w okresie rosnącej popularności rozwiązań producentów oprogramowania do ochrony prywatności. Wszystkie operacje nie dzieją się, tak jak ma to miejsce np. w Facebook Pixel, na urządzeniu konsumenta, tylko po stronie serwera, przez co przeglądarki i inne programy nie wykrywają integracji tego typu
• informacje są bardziej precyzyjne: obecnie odbiorcy przy minimalnej świadomości programistycznej są w stanie manipulować końcowymi danymi, przez co mogą zaburzyć dokładność pomiarów (np. wysyłając celowo X razy informację o zakupie Y produktów za cenę Z, faktycznie tego nie robiąc)
• dokładniejsza segmentacja audiencji: Meta (Facebook) Conversions API pozwala (i zaleca) na przesyłanie wielu szczegółowych informacji, takich jak adres e-mail, numer telefonu, wewnętrzny identyfikator odbiorcy w ramach usługi, kod pocztowy itd. Ta możliwość, w połączeniu z brakiem możliwości jakiejkolwiek manipulacji po stronie odbiorcy, pozwala na dokładniejsze podzielenie odbiorców w podgrupy, np.: grupa osób, która zrealizowała zakupy, ale wcześniej zrobiła szereg innych czynności

Jak widać, możliwości jest bardzo dużo i niewątpliwie, rosnąca popularność tego rozwiązania, przyczyni się do dokładniejszego spojrzenia na kwestie analityczne obsługiwanych usług.

Wady Meta (Facebook) Conversions API

Interfejs programistyczny Mety (Facebooka) dostarcza wiele ścieżek określania profilu naszych odbiorców, jednak wiąże się ono z pewnymi wadami:

• mierzenie danych jest ograniczone głównie konstrukcją usługi: wada, która jednocześnie jest zaletą. Jak na początku wspomniałem, Meta (Facebook) Conversions API jest rozwiązaniem serwerowymi (ang. server-side), a nie klienckim (ang. client-side), takim jak np. Meta (Facebook) Pixel. Implementacja tego API wiąże się z modyfikacją usługi, co może wiązać się z utrudnieniami na etapie programistycznym
• wymagana wiedza programistyczna: załączenie tego rozwiązania jest niemożliwe bez posiadania specjalistycznej wiedzy. Mimo obecności już gotowych rozwiązań na rynku dochodzi szereg problemów na etapie serwisowania oprogramowania (m.in. elastyczność podpięcia, aktualizacje itd.). Działania tego typu wymagają przeznaczenia odpowiednich zasobów (finansowych i/lub czasowych)
• problem ze skalowaniem: popularne narzędzie Meta (Facebook) Pixel wysyła informacje po stronie klienta (ang. client-side) — jedynym obowiązkiem osób dokonujących integracji, jest zainstalowanie odpowiedniego skryptu śledzącego i oznaczenie miejsc raportowania (szczegółowo opisałem to tutaj). Pozostałe procesy dzieją się samodzielnie i niezależnie od infrastruktury usługi, dane są przesyłane do Mety (Facebooka). Przy rozwiązaniach serwerowych, trzeba uwzględnić natężenie ruchu, a co za tym idzie, generowane obciążenie: im więcej ruchu, tym jest ono większe
• szczegółowa analiza ścieżek klienta: samo wysyłanie informacji nic nie daje, jeśli nie wyznaczy się obiegu odbiorcy w ramach oferowanej usługi. Jak będziesz mieć okazję przekonać się poniżej, kluczowe dla przesyłania informacji jest to, by móc "łapać" odbiorcę w momentach, w których ujawni swoją tożsamość: poprzez zostawienie adresu e-mail, zarejestrowanie się itd. Samo wysłanie konwersji jest tylko oznaczeniem tego, że dana interakcja została wykonana: bez danych identyfikujących nie będziesz w stanie określić, kto to zrobił i dotrzeć do niego w późniejszym czasie (np. poprzez remarketing)

Zapewniam jednak, iż warto pokonać wyżej wymienione trudności i zacząć działać już dziś: zmiany w zakresie przepływu danych następują szybko.

Jak działa Meta (Facebook) Conversions API?

Kluczem do zrozumienia działania Meta (Facebook) Conversions API jest ustalenie niezbędnych struktur danych, z jakimi zachodzi styczność podczas raportowania konwersji oraz sposoby wiązania danych z konkretnym odbiorcą. Niezbędna tutaj także jest znajomość funkcjonowania Meta (Facebook) Pixel, którą opisałem w tym wpisie. Dodatkowo poruszę kwestię związaną z walidacją duplikatów zapytań.

Wiązanie danych z konkretnym odbiorcą

Na chwilę pisania artykułu, podstawowym sposobem identyfikacji odbiorców są ciasteczka (ang. cookies) — specjalnych pakietów, przechowujących dane. Facebook, jako podmiot zewnętrzny dla naszej usługi, korzysta z plików cookies kategorii trzeciej (ang. third-party cookies), dzięki czemu wiąże nas ze swoimi bazami danych i śledzi aktywność na każdej witrynie, gdzie jest zainstalowany Meta (Facebook) Pixel. Dane, jakie zapisuje, są dwa:

• ciastko _fbp: identyfikator naszej przeglądarki (generowany przez Metę [Facebooka])
• ciastko _fbc: identyfikator lokalizacji, z której dotarliśmy na stronę, np. reklamy (generowany na podstawie danych od Mety [Facebooka])

Ponadto, istnieje możliwość (lub przymus, jeśli nie jest możliwe dostarczenie dwóch powyższych identyfikator i chcemy docierać do naszego odbiorcy) uzupełnienia stosu danych o naszym konsumencie, wśród których zalicza się m.in.:

• adres e-mail
• numer telefonu
• miasto, województwo, kod pocztowy

Lista wszystkich parametrów znajduje się tutaj.

Ciasteczko _fbc

Ciasteczko _fbc różni się od _fbp tym, iż jest ono generowane na podstawie informacji przesłanych przez Facebook, a nie przez niego samego. Oznacza to tyle, że należy je samodzielnie wygenerować. Przydatny może być poniższy fragment kodu (który napisałem na potrzeby tego wpisu w PHP, jednym z najpopularniejszych języków programowania na świecie):

<?php

class FacebookParameterBuilder
{

    private $version = "fb";
    private $index;
    private $creationTime;
    private $value;

    public function setIndex(int $index)
    {
        $this->index = $index;
    }

    public function setCreationTime(float $creationTime)
    {
        $this->creationTime = $creationTime;

        return $this;
    }

    public function setValue(string $value)
    {
        $this->value = $value;

        return $this;
    }

    public function build()
    {
        if ($this->index == null || $this->creationTime == null || $this->value == null
            || empty($this->index) || empty($this->creationTime) || empty($this->value))
        {
            throw new InvalidArgumentException('All fields must be filled');
        }

        return $this->version . "." . $this->index . "." . $this->creationTime . "." . $this->value;
    }

}

Ciastko _fbc składa się z czterech elementów:

• version: jest to prefiks ciastka, zawsze ma wartość fb
• subdomainIndex, bądź index: definiuje lokację stworzenia naszego ciasteczka (jeśli cookie jest generowany w warstwie serwerowej, powinien być zawsze 1)
• creationTime: czas w formacie UNIX, który oznacza chwile stworzenia ciasteczka
• value: właściwa wartość ciastka, która jest generowana z parametru fbclid zawartego w linku, na który przekierowuje nas Meta (Facebook)

Każdy z tych elementów jest oddzielony znakiem kropki (.), na przykład:

fb.1.1554763741205.AbCdEfGhIjKlMnOpQrStUvWxYz1234567890

Struktura zdarzenia

Strukturę zdarzenia należy podzielić na część serwerową i zawartą w niej część własną.

Część serwerowa określa główny fragment struktury zapytania, w niej określamy takie podstawowe informacje jak nazwa konwersji, czas jej przesłania, czy źródło:

{
    "event_name": "Purchase",
    "event_time": 0000000000,
    "user_data": {
        "em": "7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068"
    },
    "custom_data": {
        "currency": "PLN",
        "value": "100"
    }
}

Część własna z kolei definiuje własności każdego ze zdarzeń: opisuje konkretne wartości i zawiera niestandardowe informacje. Pola tego typu muszą być w obiekcie custom_data.

Duplikaty zdarzeń

Niespójności w analityce są jedną z najbardziej niechcianych rzeczy, na szczęście Meta (Facebook) Conversions API posiada mechanizm eliminujący tę niedogodność. Jeśli dane są przesyłane jednocześnie poprzez kod śledzący Meta (Facebook) Pixel i API konwersji, wystarczy do części serwerowej załączyć pole z unikalną wartością dla każdego z wydarzeń: event_id. Dzięki temu, dla wszystkich kombinacji związanych z tożsamą konwersją i tym samym unikalnym identyfikatorem, wydarzenia nie zostaną przetworzone.

Następnie, należy oznaczyć wydarzenia przesyłane przez Meta (Facebook) Pixel tym samym zestawem informacji:

fbq('track', 'Purchase', {currency: "PLN", value: 50.00}, {eventID: "EVENT_ID"});

Wysyłanie zapytania

Po stworzeniu struktury zdarzeń i zadbaniu o wymagane dane należy opakować nasze wydarzenia w obiekt data:

{
    "data": [
        {
           "event_name": "Purchase",
           "event_time": 0000000000,
           "user_data": {
               "em": "7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068"
           },
           "custom_data": {
               "currency": "PLN",
               "value": "100"
          }
       }
    ]
}

Przy tworzeniu całego ciała zapytania warto pamiętać, iż limit zdarzeń na jedno zapytanie wynosi 1000.

Następnie, pozostaje wykonanie zapytania typu POST na określony adres URL (na przykładzie pakietu curl):

curl -X POST \
  -F 'data=[
       {
           "event_name": "Purchase",
           "event_time": 0000000000,
           "user_data": {
               "em": "7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068"
           },
           "custom_data": {
               "currency": "PLN",
               "value": 100
           }
       }
     ]' \
  -F 'access_token=<ACCESS_TOKEN>' \
  https://graph.facebook.com/v9.0/<PIXEL_ID>/events

Token dostępu

Każda wysłana paczka danych musi być podpisana odpowiednim kluczem autoryzacyjnym. Wygenerować można go w ustawieniach Piksela, podłączonego pod konto reklamowe. Następnie, w parametrze zapytania access_token należy zamienić przykładową wartość <ACCESS_TOKEN> na wygenerowany klucz.

Tutaj warto także wspomnieć o podsekcji Konfiguracja za pośrednictwem integracji partnerskiej, gdzie Facebook udostępnia już gotowe rozwiązania dla wybranych platform z instrukcją krok po kroku.Testowanie zdarzeń

Jednym z narzędzi diagnostycznych do prawidłowej weryfikacji instalacji śledzenia danych jest Testowanie zdarzeń. W ramach niego dostajemy pogrupowane wydarzenia wraz ze szczegółami, które są przesyłane.

Oprócz mierzenia interakcji z poziomu przeglądarki Meta (Facebook) umożliwia podpisywanie zapytań specjalnym parametrem testowym, który powoduje wyszczególnienie zdarzeń w tej sekcji. Wystarczy, iż to ciała zapytania dołożymy parametr test_event_code z wyróżnioną zawartością.

{
    "data": [
        {
           "event_name": "Purchase",
           "event_time": 0000000000,
           "user_data": {
               "em": "7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068"
           },
           "custom_data": {
               "currency": "PLN",
               "value": 100
          }
       }
    ],
    "test_event_code": "TEST00000"
}

Obsługa błędów

Obsługa błędów jest istotna dla pracy z Meta (Facebook) Conversions API i lokalizowania źródeł nieprawidłowego funkcjonowania raportowania danych z usługi. Domyślnie zapytanie powinno zwracać kod zapytania HTTP 2xx, jeśli wystąpi błąd: 4xx. W celu uzyskania dokładnej informacji o niepowodzeniu należy zmodyfikować URL zapytania w następujący sposób:

https://graph.facebook.com/v9.0/<PIXEL_ID>/events?trace=[1-3]

W miejsce wartości parametru trace funkcjonują następujące wartości:

• 1 - wyświetlenie szczegółów błędu
• 2 - wyświetlenie ogólnych informacji
• 3 - wyświetlenie informacji deweloperskich

Meta (Facebook) Conversions API to inny standard przesyłania danych, jednak jak możesz zauważyć — bardzo wartościowy i nadający nowe znaczenie analityce działań z kanału dystrybucji treści, jakim jest Facebook.

Konwersje zdarzeń w ramach narzędzia, jakim jest Facebook Pixel, można podzielić na standardowe i niestandardowe.

Zdarzenia standardowe można definiować jako te, które są określone w oficjalnej specyfikacji, gdzie jest wymóg wysyłania odpowiednich informacji dla przesłania poszczególnego pakietu danych. Zapewniają one sprawniejszą obsługę działań reklamowych w systemie Facebook.

Jak ustawić standardowe zdarzenia w Meta (Facebook) Pixel?

Standardowe zdarzenia w narzędziu Facebook Pixel służą do definiowania kluczowych zachowań na stronie internetowej i późniejszej ich analizy. Pokażę, jak to prawidłowo zrobić.

Kacper DurasKacper Duras

Czasem jednak zachodzi potrzeba zdefiniowania dodatkowych kryteriów, względem których będziemy segmentować odbiorców na tych, którzy faktycznie będą mieli znaczący kontakt z naszym usługami, a na tych, których prawdopodobieństwo spełnienia określonej interakcji będzie bardzo małe. W odpowiedzi na to wyzwanie przychodzą zdarzenia niestandardowe.

Czym są zdarzenia niestandardowe?

Zdarzenia niestandardowe to specjalne oznaczenia, służące do śledzenia interakcji odbiorców konkretnej usługi, które domyślnie nie są zawarte w ramach dokumentacji technicznej sieci reklamowej firmy Facebook. Dzięki załączaniu dodatkowych informacji poprzez zdarzenia niestandardowe zyskuje się możliwość prowadzenia dogłębniejszych działań reklamowych.

Z czego składają się zdarzenia niestandardowe?

Raportowanie zdarzeń niestandardowych jest podobne do standardowych odpowiedników konwersji. Konstrukcja wygląda w następujący sposób:

fbq('trackCustom', '[event]', {
  param: 'value'
});

Po prawidłowej instalacji Facebook Pixel, do użycia w kodzie strony będzie możliwa funkcja z języka JavaScript fbq, która względem zdarzeń standardowych różni się następującymi cechami:

• zamiana polecenia track na trackCustom
• limit 50 znaków dla nazwy zdarzenia niestandardowego

Podobna integracja może być realizowana w warstwie serwerowej usługi dzięki Facebook Conversions API (jest to zalecane rozwiązanie do równoległego użycia z Facebook Pixel).

Ograniczenia zdarzeń niestandardowych

Używanie zdarzeń niestandardowych podlega licznym ograniczeniom, do których przyczyniły się m.in. zmiany firmy Apple dotyczące śledzenia interakcji odbiorców i ograniczania żywotności plików cookies. Z bezpośrednich regulacji można wyróżnić:

• ograniczenie ilości rodzajów zdarzeń do ośmiu na jeden Facebook Pixel (łącznie ze zdarzeniami standardowymi)
• obowiązek konfiguracji zdarzeń webowych i wyznaczenia ich priorytetów

Zastosowanie zdarzeń niestandardowych

Mierzenie konwersji tego typu ma przede wszystkim zastosowanie w segmentowaniu odbiorców, którzy wykonali określone interakcje na stronie, których nie można zakwalifikować jako standardowe. Na podstawie tych informacji, można np. utworzyć grupę niestandardowych odbiorców, określając nasze zdarzenie jako warunek konieczny do wyodrębnienia

Udostępnianie danych ze zdarzeń niestandardowych

Warto wspomnieć także o tym, że istnieje możliwość udostępnienia niestandardowych konwersji podmiotom trzecim, dzięki czemu nie ma potrzeby ujawniania wszystkich danych dot. użytkowników: jest to wysoce przydatne przy pracy z podmiotami zewnętrznymi, które niekoniecznie potrzebują aż tak wysokich uprawnień do przetwarzania informacji. W tym celu należy udostępnić skonfigurowany Pixel.

Meta (Facebook Pixel) to rozwiązanie o dużym potencjalne dla małych, średnich, jak i wielkich reklamodawców. Udostępnione narzędzie od Mety (Facebooka) umożliwia m.in. szczegółową analizę danych, segmentowanie użytkowników, czy integrację z całym systemem informacyjnym cyfrowego giganta, dzięki któremu możemy docierać w licznych formatach reklamowych do pożądanych przez nas odbiorców. Podstawy omówiłem w moim poprzednim wpisie:

Co to jest Meta (Facebook) Pixel i jak on działa?

Piksel Facebooka (ang. Facebook Pixel) to rozwiązanie firmy Facebook do mierzenia aktywności odbiorców na stronie internetowej.

Kacper DurasKacper Duras

Dziś opowiem, jak mierzyć prawidłowo dane za pomocą standardowych wydarzeń w Meta (Facebook) Pixel.

Zdarzenia i ich rodzaje

W wyżej wymienionym artykule napisałem:

Pixel to jest mały fragment kodu JavaScript, który odpowiada za mierzenie działań na stronie, nazywanych zdarzeniami.

Facebook w swojej dokumentacji odnośnie narzędzia informuje o dwóch rodzajach zdarzeń:

• standardowe, tj. określone w oficjalnej specyfikacji, gdzie jest wymóg wysyłania odpowiednich informacji dla przesłania poszczególnego pakietu danych
• niestandardowe, czyli definiowane samodzielnie przez użytkowników

Drugi rodzaj zdarzeń jest o wiele bardziej złożony i ma faktyczne zastosowanie przy mierzeniu niecodziennych interakcji i wskaźników na stronie, które mogą służyć jako mocno szczegółowe kryteria np. do segmentowania odbiorców w kierowaniu poszczególnych reklam. W praktyce ten typ ma zastosowanie głównie w sytuacji posiadania usługi z bardzo dużym ruchem, dlatego w większości przypadków sprawdzą się standardowe zdarzenia.

Z czego składają się zdarzenia standardowe?

Konstrukcja wygląda w następujący sposób:

fbq('track', '[event]', {
  param: value
});

Przy załączeniu kodu śledzącego Pixela definiowana jest funkcja fbq, za pomocą której możemy przesyłać informacje w standaryzowanej formie.

Pierwszym parametrem jest track, czyli informacja o tym, że dany fragment kodu ma służyć do wysyłania informacji o danym zdarzeniu. Następnie, w kolejnym parametrze należy dostarczyć informacje o tym, jaki rodzaj wydarzenia standardowego jest do przesłania. Pełna lista dostępnych wariantów znajduje się tutaj. Trzecim argumentem jest tzw. obiekt JSON, czyli specjalny format danych do wymiany informacji pomiędzy systemami informatycznymi. W tym elemencie umieszczamy wartości, potrzebne do prawidłowego pomiaru danych. Co ważne, nie musimy dostarczać identyfikatora użytkownika - Pixel dane przypisze do odbiorców w sposób automatyczny.

Przykład implementacji

<html>
  <head>
    <title>Przykładowa implementacja Facebook Pixel</title>
    <script>
      !function(f,b,e,v,n,t,s)
      {if(f.fbq)return;n=f.fbq=function(){n.callMethod?
      n.callMethod.apply(n,arguments):n.queue.push(arguments)};
      if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
      n.queue=[];t=b.createElement(e);t.async=!0;
      t.src=v;s=b.getElementsByTagName(e)[0];
      s.parentNode.insertBefore(t,s)}(window, document,'script',
      'https://connect.facebook.net/en_US/fbevents.js');
      fbq('init', '[id]');
      fbq('track', 'PageView');
    </script>
  </head>
  
  <body>
    <button type="button" onclick="fbq('track', 'Purchase', {currency: "PLN", value: 50.00});
">Wyślij informacje o zakupie</button>
  </body>
</html>

Powyższy przykład to przykładowa strona napisana w języku HTML (i kodu JavaScripta, potrzebnego dla poprawnego działania rozszerzenia).

W sekcji head umieszczony jest oficjalny kod implementacyjny Pixela. Składa się on z trzech elementów:

• zdefiniowanie funkcji fbq, dzięki której możemy przesłać dane
• wysłanie polecenia init do docelowego Pixela
• raportowanie podstawowego wydarzenia PageView, które informuje o załadowaniu się strony internetowej

Z kolei w sekcji body na potrzeby demonstracyjne przygotowałem przycisk, po którego kliknięciu wykonuje się kod z parametru onclick, który wygląda następująco:

fbq('track', 'Purchase', {currency: "PLN", value: 50.00});

Fragment definiuje to, że wysyłamy zdarzenie Purchase z dwiema informacjami: o walucie przykładowej transakcji (tj. PLN) i o wolumenie (tj. 50). Pełna lista parametrów dla każdego ze zdarzeń znajduje się tutaj.

Najważniejsze zdarzenia standardowe

Nie wszystkie zdarzenia standardowe należy implementować, jednak przy analizie konstrukcji strony internetowej szczególnie na te warto zwrócić uwagę, gdyż bardzo często będą pojawiały się przy pracy z narzędziami Mety (Facebooka):

• PageView — podstawowe wydarzenie informujące o załadowaniu strony internetowej, dostarczane domyślnie w podstawowym kodzie Pixela
• ViewContent — wyświetlenie ważnej zawartości, np. karty produktu
• AddToCart — informacja o dodaniu produktu do koszyka (szczególnie przydatne w e-commerce)
• AddPaymentInfo — dodanie danych do dostawy, płatności etc.
• InitiateCheckout — rozpoczęcie procedury płatności
• Purchase — końcowy zakup
• Search — korzystanie z wewnętrznej wyszukiwarki w domenie
• Contact — skorzystanie z formularza kontaktowego
• Lead — informacja o wypełnieniu formularza (newsletterowego, zgłoszeniowego etc.)

Weryfikacja poprawności instalacji

Sama instalacja może być procesem skomplikowanym, dlatego przed wypuszczeniem usługi do działania produkcyjnego, warto zweryfikować czy zmiany na stronie załączyły się poprawnie. Do pomocy przychodzi wtyczka dla przeglądarki Google Chrome o nazwie Facebook Pixel Helper, która:

• sprawdza, czy Pixel uruchamia się na stronie
• weryfikuje, jakie wydarzenia są wysyłane
• pokazuje informacje przesłane do Mety (Facebooka)

Rozszerzenie jest dostępne za darmo w Chrome Web Store.

Piksel Mety [Facebooka] (ang. Meta [Facebook] Pixel) to rozwiązanie firmy Meta do mierzenia aktywności odbiorców na stronie internetowej i wiązania konkretnych interakcji z działaniami reklamowymi. Jest to podstawowe narzędzie do prowadzenia płatnych kampanii w ramach sieci reklamowej Mety (Facebooka).

Jak działa Meta (Facebook) Pixel?

Meta (Facebook) Pixel funkcjonuje jako fragment kodu JavaScript — specjalnego języka skryptowego, przeznaczonego do tworzenia zaawansowanych funkcjonalności usług internetowych. Reklamodawcy w ramach prowadzenia działań reklamowych, dostają specjalnie wygenerowaną treść, którą muszą załączyć do witryny internetowej. Następnie, po prawidłowej instalacji i oznaczeniu wydarzeń, Meta (Facebook) Pixel wysyła wszystkie niezbędne informacje do sieci reklamowej, wiążąc profile odbiorców z informacjami udostępnionymi w ramach ekosystemu Mety (Facebooka).

Meta (Facebook) Pixel w swoim funkcjonowaniu stosuje pliki cookies, które pozwalają na przechowywanie informacji na urządzeniach odbiorców. Działanie to ma na celu dokładniejsze segmentowanie audiencji, co pozwala na precyzyjniejsze dobieranie zawartości reklamowych.

Pliki cookies

Meta (Facebook) Pixel, jak wyżej wspomniałem, stosuje pliki cookies określone jako pliki trzeciej kategorii — oznacza to, iż informacje tego typu generowane są przez zewnętrzny podmiot dla naszego serwisu, jakim jest Meta.

Narzędzie to tworzy następujące ciasteczka:

• ciastko _fbp: identyfikator naszej przeglądarki (generowany przez Metę)
• ciastko _fbc: identyfikator lokalizacji, z której dotarliśmy na stronę, np. reklamy (generowany na podstawie danych od Mety)

Każde z nich ma kompletnie inną konstrukcję, która różni się w zależności od sytuacji.

Ciasteczko _fbp

Plik cookie o nazwie _fbp jest identyfikatorem urządzenia, z jakim się łączymy: jest to szczególnie ważna informacja, ponieważ w dzisiejszych czasach odbiorcy dokonują interakcji z różnych urządzeń (np. telefony, tablety, zegarki etc.). Dzięki niemu reklamodawcy mają świadomość na temat przekroju aktywności urządzeń w ramach witryny, jak i są w stanie mierzyć drogę klienta od zbudowania uwagi, do docelowej konwersji.

Ważną informacją jest to, że ciastko _fbp nie utworzy się, jeśli:

• przeglądarka lub inne zainstalowane oprogramowanie będzie blokowało ciasta reklamowe podmiotów trzecich
• urządzenie będzie miało wyłączone zapisywanie plików cookies

Jest to na tyle spore utrudnienie, iż nie pozwala na dotarcie do odbiorców, którzy mają kontakt z naszą usługą z ruchu innego, niż Facebook. Rozwiązaniem, które przychodzi na pomoc temu problemowi jest Meta (Facebook) Conversions API.

Ciasteczko _fbc

Plik cookie o nazwie _fbc jest identyfikatorem, który pozwala na zdefiniowanie rodzaju umiejscowienia na Facebooku, z jakiego przychodzą odbiorcy do witryny (np. reklama, link w Messengerze). Co ważne, ciastko to może być utworzone niezależnie od ustawień prywatności przeglądarki — sposób tworzenia znajduje się w moim wpisie nt. Meta (Facebook) Conversions API.

Końcowe zapytanie

Meta (Facebook) Pixel w ramach udostępnianego kodu JavaScript wykonuje warstwe logiczną związaną z zapisywaniem ciasteczek na końcowych urządzeniach użytkowników, jak i wysyłaniem informacji w specjalnym formacie do Facebooka.

Ostateczne zapytanie, jakie nasze urządzenie skieruje do Facebooka, kierowane jest na niniejszy link:

https://facebook.com/tr/

Łącze za każdym razem zwraca przeźroczysty obrazek w wymiarze 1px na 1px, niezależnie od tego, jakie informacje prześlemy. Jest to sposób na rozwiązanie problemów z bezpieczeństwem, związanego z wysyłaniem informacji do zewnętrznych podmiotów. Wszystko zależy od tego, jakie informacje zawrzemy w parametrach linku.

Zastosowania Meta (Facebook) Pixel

Meta (Facebook) Pixel jest podstawowym narzędziem służącym do mierzenia interakcji odbiorców w ramach oferowanej witryny. Tym samym, dzięki niemu możemy zrealizować takie czynności jak:

• docieranie ponowne do odbiorców (tzw. remarketing)
• segmentowanie audiencji względem określonych aktywności (np. wypełnienie specjalnego formularza)
• raportowanie końcowych konwersji na cele statystyczne (np. skuteczność reklamy)

Ponadto, Meta (Facebook) Pixel przy wysyłaniu określonych zdarzeń umożliwia dostarczanie specjalnych parametrów, które dostarczają precyzyjniejsze szczegóły realizacji interakcji.

Tyle, i aż tyle: jak możesz zauważyć, bez niego skuteczne reklamowanie się nie jest możliwe.

Jak zainstalować Meta (Facebook) Pixel?

Instalacja kodu Meta (Facebook) Pixel jest bardzo prosta:

1. Przejdź do Menedżera zdarzeń i wybierz kto ma być właścicielem Piksela (dla firm posiadających Menadżera Biznesowego)
2. Kliknij Połącz źródła danych i wybierz opcję Witryna.
3. Wybierz Piksel Facebooka i kliknij Połącz.
4. Dodaj nazwę piksela.
5. Wprowadź adres URL witryny, aby sprawdzić opcje łatwej konfiguracji.
6. Kliknij Kontynuuj.

Następnie system zaproponuje dostępne możliwości automatycznych integracji. Jeśli nie będzie to wykonalne, zostanie załączona instrukcja jak zainstalować kod śledzący manualnie.

Kod manualny Meta (Facebook) Pixel

Instalacja kodu ręcznie będzie przy prowadzeniu działań reklamowych bardzo często spotykana. Ma on następującą strukturę:

<!-- Facebook Pixel Code -->
<script>
  !function(f,b,e,v,n,t,s)
  {if(f.fbq)return;n=f.fbq=function(){n.callMethod?
  n.callMethod.apply(n,arguments):n.queue.push(arguments)};
  if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
  n.queue=[];t=b.createElement(e);t.async=!0;
  t.src=v;s=b.getElementsByTagName(e)[0];
  s.parentNode.insertBefore(t,s)}(window, document,'script',
  'https://connect.facebook.net/en_US/fbevents.js');
  fbq('init', '[id]');
  fbq('track', 'PageView');
</script>
<!-- End Facebook Pixel Code -->

Składa się on z trzech następujących elementów:

• kodu inicjujący, definiującego start ładowania skryptu
• polecenia init, który określa do jakiego Piksela (czyli miejsca przechowywania informacji) ma przesyłać informacje. Ważne: Piksel to nie jest Facebook Pixel. To pierwsze jest pozycją w Menedżerze zdarzeń
• polecenia track, które wysyła zdarzenie PageView, czyli podstawową informację o wyświetleniu Twojej witryny

Jak oznaczać zdarzenia przy pomocy Meta (Facebook) Pixel?

Meta (Facebook) Pixel na etapie inicjacji, stworzył w kodzie naszej strony funkcję fbq:

fbq('track', 'Purchase', {currency: "PLN", value: 50.00});

Fragment kodu tego typu zawiera takie informacje:

• track, czyli rodzaj polecenia, jakie jest wysyłane
• Purchase, czyli typ załączonego zdarzenia
• currency i value, czyli wartości charakterystyczne dla każdego zdarzenia

Pełna lista zdarzeń i dostępnych parametrów znajduje się tutaj.

Fragment kodu podobnego typu należy wykonać przy wykonaniu interakcji zgodnej z logiką biznesową aplikacji. Więcej informacji umieściłem tutaj.

Wady Meta (Facebook) Pixel

Meta (Facebook) Pixel jako narzędzie stosujące do swojego działania pliki cookies trzeciej kategorii jest stopniowo blokowane przez rozwiązania służące do ochrony prywatności odbiorców. Więcej o tym trendzie i o jednej z metod przeciwdziałania, napisałem tutaj we wpisie na temat Meta (Facebook) Conversions API:

Jeżeli korzystasz z reklam na Facebooku lub dopiero zamierzasz przeznaczyć swój budżet na nową reklamę w mediach społecznościowych, pamiętaj, aby skonfigurować Meta (Facebook) Pixel.

Pomoże Ci on szybko i skutecznie zoptymalizować Twoją reklamę. Tak, aby trafiać do jak najlepszej grupy odbiorców, a przy tym mierzyć kluczowe konwersje dla Twojej usługi.

Jednym z popularniejszych problemów w planowaniu kampanii reklamowej jest ustalenie jej budżetu. Często po analizie możliwości biznesowych reklamodawcy mamy odpowiedzi na pytania, co chcemy uzyskać i za ile, ale nie jak to rozplanować. Pomocne w odpowiedzi na to pytanie może być rozwiązanie oferowane przez samego Facebooka.

Optymalizacja budżetu kampanii (ang. Campaign Budget Optimisation) to funkcjonalność wprowadzona w sierpniu 2019 (wstępnie jako obowiązkowa dla wszystkich, później zmieniona jako zalecana, lecz opcjonalna), mająca w założeniu odpowiadać na problemy reklamodawców związane z zarządzaniem budżetem w ramach zestawów reklam. Konstrukcja jest na pozór prosta, albowiem wymogiem jest konfiguracja kwoty kampanii nie na etapie tworzenia zestawu reklamowego (jak to było w znanym nam wszystkim, pierwotnym zamyśle), a całej kampanii. Jest to niewątpliwie krok w przód do oddania zarządzania działaniami reklamowymi algorytmom, jednak warto spojrzeć na dobre i złe strony tego rozwiązania.

Założenie modelu

Optymalizacja budżetu kampanii wykorzystuje budżet kampanii oraz strategię składania ofert (która przy zastosowaniu rozwiązania, musi być jednolita dla wszystkich zawartych zestawów reklam), np. najniższy koszt uzyskania działania, w celu automatycznego i ciągłego znajdowania aktywnych okazji do uzyskania oczekiwanych wyników przez reklamy. Co warto zaznaczyć, CBO uwzględnia harmonogramy zaplanowanych zestawów, więc nie powinno być problemu przy skalowaniu dziań i rozdzielaniu zasobów finansowych przy większej ilości kolekcji (która według oficjalnej dokumentacji Facebooka może wynosić aż 200!), przy jednoczesnej, aktualnej analizie działań, w połączeniu z obranym celem reklamowym.

Jak działa to w praktyce?

Papier przyjmie wszystko, jednak praktyka pokazuje, że rozwiązania przedstawiane zazwyczaj jako lepsze, bardzo często sprawiają problemy i obniżają jakość przeprowadzanych działań reklamowych. Głównym założeniem CBO jest jak najtańszy koszt wykonania przez odbiorcę akcji, jaką określa cel reklamowy. W związku z tym, rozdzielając budżet na najbardziej skuteczne zestawy reklam, wybiera często te, w których koszt dotarcia jest najniższy i mocno promuje je do końca trwania kampanii, co niekoniecznie musi wiązać się z tym, że premiuje te zestawy, które przynoszą najbardziej wartościowe konwersje (np. zakup). Dlatego pomimo zastosowanego CBO, trzeba dalej cały czas doglądać reklamy. Trzeba również zaznaczyć, że optymalizacja budżetu na poziomie kampanii nie wyłączy wszystkich zbędnych zestawów reklam. Facebook pozbędzie się jedynie wartości skrajnych, a reszcie reklam będzie rozdzielał budżet w zależności od zapotrzebowania.

Czego nie robić?

1. Nie testuj za pomocą CBO kreacji

Po pierwsze, od tego są właściwe testy A/B, które optymalizują reklamy pod kątem wyłonienia lepszego wskaźnika. Po drugie, tańszy wynik nie oznacza wartościowego rezultatu - czasem złotówka za kliknięcie więcej może być niczym w naszym budżecie, a w rezultacie pozwoli dopiąć kolejną wartościową konwersję.

2. Nie ustawiaj w ramach jednej kampanii kilku skrajnych grup docelowych

Grupy oparte na zainteresowaniach, podobne, niestandardowe - brzmi cudownie, a automatyczna optymalizacja powoduje, że świat staje się bajką. Niestety tak nie jest, a CBO jak wyżej wspomniałem, premiuje zestawy przynoszące najwięcej tanich konwersji, a bardzo często takimi są grupy remarketingowe, więc jak stosujesz CBO - rozdzielaj grupy w kampaniach!

3. Dobierz odpowiedni cel reklamowy

Wszystkie cele zawarte w zakładce Konwersje wymagają dużej ilości danych, więc CBO nie jest panaceum na nagły wzrost sprzedaży o np. 300% :) Lepiej zastosować pozostałe cele, jak np. te z kategorii Działania.

Dobre praktyki

1. Stosuj limit wydatków

Każdy zestaw w ramach CBO może mieć skonfigurowany limit wydatków. Warto z niego skorzystać i pomimo powierzenia części pola automatowi, ustalić górną granicę tak, by kontrolować optymalizacje reklam - w momencie ustabilizowania, można wyłączyć zbędne zestawy i poluzować reguły wydatkowe.

2. Użyj tam, gdzie faktycznie potrzebujesz tylko taniego ruchu

Użyteczne jest to np. w celu Aktywność, który dla końcowego odbiorcy nie jest wymagający, a dla reklamodawcy jest bardzo tani, a może być przy dużej grupie docelowej jeszcze tańszy.