#5: Analizowanie konkurencji w e-commerce, czyli jak być data-driven na poważnie
W dodatku bez użycia jakiejkolwiek formy sztucznej inteligencji
Cześć,
ostatni wpis przesłałem ponad miesiąc temu — co prawda obiecałem sobie, że będę tworzył treści zdecydowanie częściej, acz:
Piszę wtedy, kiedy mam na to pomysł. To zresztą jedna z zasad tego newslettera, którą ustaliłem sobie na samym początku zakładania go i zdecydowanie się tego trzymam. Nie widzę sensu tworzenia zawartości po to, by coś napisać (acz pierwotny wpis który planowałem opublikuję jako następny).
Miałem zamiar pod koniec tamtego miesiąca wrzucić do Internetu bardzo fajną rzecz, acz z racji na moje bieżące obowiązki trochę się to niestety przedłuży i wyrobię się dopiero pod koniec sierpnia — zanotyfikuję Cię, gdyż to będzie bardzo przydatna rzecz poprzedzona bardzo drobiazgowym researchem.
Dzisiaj podrzucę sposób (który co prawda jest głównie ma zastosowanie w e-commerce, acz sam schemat nie jest na tyle szyty na miarę, by nie móc go zaadaptować w innej formie) na to, jak bez popadania w zbędną ekstazę i stosując mój ulubiony rodzaj wdrożeń, czyli łatwo, szybko i tanio, być firmą data-driven bez stosowania fikuśnych SaaSów w klasycznym tego słowa rozumieniu i porównywać ceny swoich produktów z konkurencją, by następnie, uwaga, dostosować na podstawie tej informacji swój budżet marketingowy i politykę cenową.
To wszystko stosując trochę kodu, narzędzia Google Cloud Platform i jakikolwiek brak stosowania AI :) Nie brzmi to za bardzo modnie, ale czymże byłyby konwenanse, gdyby nie można było ich naruszyć?
Rozpoznanie możliwości
Na pomysł wpadłem jakiś czas temu przy weryfikacji możliwości wyciągnięcia danych z różnych narzędzi od Google. Odkąd pamiętam wszystko co mogę staram konwertować do formatów baz danych takich jak np. Google BigQuery — wynika to u mnie głównie z wygody (szybciej zdecydowanie dla mnie jest napisać polecenie zamiast wyklikać interfejs, który często bywa źle zaprojektowany) i braku ograniczeń w dalszym zarządzaniu informacjami (mogę potem z tego tytułu zrobić wszystko, co mi się tylko podoba).
Otóż Google BigQuery posiada reklamowaną przez nich funkcję Google BigQuery Data Transfer, która jak sama nazwa mówi, służy do planowania transferów informacji danych z aplikacji do BigQuery. Pomijając to, że jej działanie jest momentami nieco dziwne i niezrozumiałe (o czym będzie w innym wydaniu), umożliwia uruchomienie w bardzo prosty sposób cyklicznych transferów do BigQuery i co za tym idzie, zapisu informacji. Integracji jest względnie sporo (acz bez możliwości dopisania własnych): od Google Ads, po nawet produkty reklamowe konkurencji (np. Meta). Jedną z nich jest Google Merchant Center, gdzie na dzień publikacji wpisu, mamy możliwość uzyskiwania następujących zestawień:
Wszystko byłoby do tego miejsca świetnie, gdyby nie to, że Google ze względu na brak uzasadnionego interesu oraz przepisy antymonopolowe nie ujawnia wielu danych, w tym bardzo precyzyjnych nt. konkurencji. Wszystko jest wyświetlane albo w sposób kohortowy (inaczej: zbiorczy, grupując np. konkurentów do grup i zestawiając zbiory ze sobą) albo z dużym opóźnieniem (gdzie w Google Ads to jest aż trzy dni!).
Informacje o statusach produktów dostajemy od razu, gdzie z doświadczenia polecam transferować je raz na dobę — do większości zastosowań to zdecydowanie wystarczy, ale sytuacja robi się tragiczna, gdy chcemy reagować w czasie rzeczywistym lub mieć bardziej precyzyjne informacje.
Automatyczne rabaty w Google Ads
Na problemy które tworzy Google odpowiada… Google. Od około roku w ramach narzędzia Google Merchant Center jest udostępniona funkcjonalność automatycznych rabatów, która pozwala na nadawanie rabatów w czasie rzeczywistym.
Sposób określania obniżek nie jest do końca wiadomy, acz według oficjalnego przekazu działa on na podstawie potencjału użytkownika do realizacji transakcji, jak i danych konkurencji — o ile cała polityka rabatowa zależna od zewnętrznego dostawcy z black-box’owym modelem jest fatalnym pomysłem, tak miałem okazję przetestować dla grup produktów charakteryzujących się:
Wysoką konkurencyjnością i zmiennością kwot, gdzie cena asortymentu może zmieniać się z godziny na godzinę (często widoczne np. w księgarniach).
Na tyle dużą marżą, że nie jest problemem zapewnienie Google’owi miejsca na automatyczną obniżek wynoszącą np. do 5% dopuszczalnej obniżki i utrzymanie polityki fiskalnej w ryzach.
Moje doświadczenia są takie, że o ile nie do końca miałem jak pomierzyć rzetelnie inkrementu przed i po wdrożeniu (nawet zważywszy na obostrzenia w reklamowaniu tego samego asortymentu z kilku porównywarek cenowych jednocześnie oraz de facto problem przy walidacji rodzaju sesji użytkownika), tak odnotowywałem zazwyczaj (co też podkreślam, bo to jest dużym uśrednieniem) większe ilości transakcji na mniejsze kwoty niż dotychczasowa średnia zakupów w całym e-commerce
Technicznie można zweryfikować wpływ tego komponentu na transakcje, gdyż każdorazowo Google przesyła informacje za pomocą JSON Web Token o tym, jaki rabat nałożyć, gdzie następnie po stronie sklepu musisz wygenerować kod rabatowy ważny przez określony czas. Cała integracja generalnie działa tak:
Zaloguj się do swojego konta Google Merchant Center.
Przejdź do sekcji "Marketing" w głównym menu, a następnie kliknij "Promocje".
Skonfiguruj dynamiczne promocje, podając:
Minimalną cenę dla automatycznego ustalania cen [auto_pricing_min_price]
Koszt towarów (COGS)
Docelowy zwrot z wydatków na reklamę (ROAS)
Maksymalny rabat promocyjny
Przykład konfiguracji w API Google Content:
Utwórz plik feedu promocyjnego w formacie CSV, XML lub JSON, zawierający szczegóły takie jak ID promocji, tytuł, opis, daty rozpoczęcia/zakończenia i kod realizacji. Przykład pliku CSV:
promotion_id,title,description,start_date,end_date,redemption_code
LATO2024,Letnia Wyprzedaż,20% zniżki na wszystkie letnie produkty,2024-06-01T00:00:00+02:00,2024-08-31T23:59:59+02:00,LATO20
Prześlij feed promocyjny do swojego konta Google Merchant Center
Przypisz promocję do konkretnych produktów lub całego asortymentu.
Przejrzyj i aktywuj promocję w interfejsie Google Merchant Center (lub zawrzyj odpowiednie reguły bezpośrednio we feedzie)
Implementacja automatycznych rabatów w Google Merchant Center wymaga dodatkowo integracji z systemem tokenów JWT. Gdy użytkownik kliknie w reklamę, zostaje przekierowany na stronę produktu z parametrem pv2 w URL, zawierającym zakodowany token. Aby obsłużyć ten token, należy dodać odpowiedni skrypt JavaScript na stronie produktowej:
Ten skrypt odczyta token i wyśle go do backendu do weryfikacji. Na backendzie, używając na przykład Pythona z frameworkiem Flask, implementujemy endpoint /verify-discount:
Ten endpoint dekoduje token, sprawdza jego ważność oraz zgodność ID oferty i sprzedawcy. Jeśli wszystko jest poprawne, zwracamy nową, obniżoną cenę produktu.
Pamiętajmy, że rabat musi być ważny przez minimum 30 minut sesji użytkownika, a dla produktów w koszyku - przez 48 godzin. Może to wymagać dodatkowej logiki w systemie koszyka i zarządzania zamówieniami.
Choć wdrożenie tego rozwiązania wymaga pewnego wysiłku, może znacząco wpłynąć na konkurencyjność oferty i zwiększyć konwersję. Jednak, jak wspomniałem wcześniej, kluczowe jest staranne monitorowanie wpływu automatycznych rabatów na ogólną rentowność sklepu i dostosowywanie strategii w miarę potrzeb. Warto również rozważyć implementację mechanizmów zabezpieczających przed nadużyciami, takimi jak wielokrotne wykorzystywanie tego samego tokenu rabatowego.
Samodzielny scrapping w czasie rzeczywistym
Dzięki API Google Merchant Center jesteśmy w stanie napisać również samodzielnie system, który realizuje scrapping w czasie rzeczywistym i niekoniecznie nas ogranicza w działaniu. Oto przykład jak:
Ten kod implementuje aplikację internetową opartą na Flask, która współpracuje z Google Content API for Shopping w celu pobierania i przetwarzania danych produktowych. Aplikacja automatyzuje proces uzyskiwania identyfikatorów REST dla produktów w koncie Google Merchant Center.
Proces rozpoczyna się od uwierzytelnienia z systemem OAuth2 Google, a następnie bezpiecznego przechowywania poświadczeń w Google Cloud Datastore. Główny przepływ pracy obejmuje pobieranie danych produktów z BigQuery (dzięki BigQuery Transfer i integracji z Google Merchant Center), a następnie wykorzystanie tych danych do wykonywania wywołań API do Google Content API for Shopping. Dla każdego produktu pobierany jest odpowiadający mu identyfikator REST. Te identyfikatory REST, które są unikalnymi identyfikatorami używanymi przez systemy Google (i jednym z wielu, co też należy podkreślić przy tworzeniu takiego “dzikiego” scrappingu), są następnie gromadzone i zapisywane z powrotem do BigQuery do przyszłego wykorzystania.
Kod obsługuje cały proces od uwierzytelnienia po pobieranie i przechowywanie danych, demonstrując jak zintegrować wiele usług Google Cloud (BigQuery, Datastore, Content API) w jednej aplikacji. Jest zaprojektowany do działania jako usługa w chmurze, potencjalnie uruchamiana przez żądania HTTP, co czyni go odpowiednim do przetwarzania dużych ilości danych produktowych w zautomatyzowany i skalowalny sposób.
Po uzyskaniu tych identyfikatorów możesz wykonać zapytanie, na przykład, do następującego linku (acz możliwości i konfiguracji jest wiele):https://www.google.pl/shopping/product/[ID]/offers
a następnie napisać logikę pobierania cen od konkurentów i zapisywania ich sobie w bazie danych lub użycia w dowolny sposób.
To wszystko
Będę wdzięczny za informację zwrotną o tym, czy taka formuła newslettera podoba się. W razie pytań odpisz na tego mejla — chętnie odpowiem i pomogę.
Do przeczytania
Kacper







Fajny tekst Kacper. Wdrożenie automatycznych zmian cen w oparciu o politykę to dość duży effort i może być bardzo duży opór zarówno z biznesu jak i z obszaru technicznego klienta. Wymaga grzebania jak piszesz w silniku e-commerce. Alternatywą jest wdrożenie np Delavo czy innego narzędzia do zarządzania kontekstem ceny. Ktoś musiałby podjąć decyzję o tym że w to idzie i zaangażować się ale na końcu prawdopodobnie miałby efekty znacznie mniej precyzyjne i gorsze niż z ww Delavo. Wobec tego moim zdaniem (mogę się mylić) bardzo ciekawe, dzięki za to ale nie jestem przekonany (samo udostępnianie COGS to będzie wyzwanie).
Drugi temat natomiast jest znacznie szybszy do wdrożenia i nie wymaga takiego effortu. Data transfery wykorzystujemy min w Data Octopus. We wrześniu prawdopodobnie przetestujemy metodę, zobaczymy jakie dane nam wpadają. Pomyślimy jaki raport ( jako kolejny) zbudować na ich postawie w naszym środowisku analitycznym oraz jak wpleść je do Master modelu danych o produktach, aby stworzyć nowe możliwości segmentacji produktów na tej podstawie. Tym sposobem możemy trochę zaadresować 1 case a effort będzie mniejszy bo np ceny w sklepie nie zmienimy ale wiedząc o tym, że np jest konkurencyjna możemy wzmocnić inwestycję w dany produkt automatycznie.
Dzięki ciekawy artykuł.
Jakbyś dał radę wrzucać kod jako txt a nie jako grafika byłym wdzięczny :)