Statystycznie istotne testy A/B dla feedów produktowych

Mierzenie, czy wysiłki optymalizacyjne były warte zachodu, od zawsze było jednym z największych wyzwań optymalizacji feedów produktowych. Dopracowanie tytułu produktu, przeformułowanie opisu produktu z pomocą AI, zmiana obrazu lub reorganizacja atrybutów produktu jest dość łatwa. Trudniej jest wiedzieć, czy zmiana faktycznie poprawiła wyniki komercyjne, czy tylko sprawiała takie wrażenie.

To pytanie ma rozstrzygać Feedoptimise A/B Testing Suite.

Zbudowany bezpośrednio w systemie zarządzania feedami produktowymi Feedoptimise, A/B Testing Suite integruje proces transformacji feedu, prowadzenia eksperymentów, zbierania danych o skuteczności na poziomie pozycji, podejmowania decyzji na ich podstawie oraz wdrażania zwycięzców w jeden spójny workflow.

Zamiast po prostu dzielić produkty na dwa segmenty i sprawdzać, który z nich dał lepsze wyniki pod względem CTR, współczynnika konwersji lub ROAS, Feedoptimise ocenia, czy różnica jest wystarczająco statystycznie istotna, aby ogłosić zwycięską wariację.

Silnik decyzyjny Feedoptimise uwzględnia takie czynniki jak poziom ufności statystycznej, przedziały ufności, minimalny lift, wielkość próby, czas trwania eksperymentu, opóźnienie konwersji oraz guardraile wydajności przy wyborze zwycięzcy.

Gdy dowody są dostępne, zwycięska wariacja jest następnie wprowadzana z powrotem do feedu poprzez kontrolowany i możliwy do podejrzenia proces wdrożenia.

To zupełnie nowe podejście do optymalizacji feedów produktowych, ponieważ sprzedawcy nie muszą wprowadzać zmiany i liczyć, że się opłaci, lecz testują hipotezę i wdrażają zmiany poparte realnymi wynikami.

Co zawiera najnowsze wydanie

• Testowanie dowolnego pola feedu. Tytuły, opisy, typy produktów, kategorie, obrazy, dowolny atrybut wyjściowy w mapowaniu feedu.
• Dwa projekty eksperymentu. Testowanie duplikowane, gdzie obie strony działają jednocześnie z różnymi identyfikatorami pozycji. Testowanie rotacyjne z tylko jednym identyfikatorem pozycji i naprzemiennym przełączaniem całej populacji w fazach.
• Twoje własne dane o skuteczności. Podłącz Google Ads, Google Analytics, Google Merchant Center, Shopify, WooCommerce, Magento, Centra, Facebook lub raport niestandardowy.
• Silnik decyzyjny z ustawieniami domyślnymi. 95% ufności, 5% minimalnego liftu, minimum 14 dni, 5 000 wyświetleń, 300 kliknięć i 30 konwersji na stronę, 7-dniowe opóźnienie konwersji oraz maksymalny czas trwania 60 dni.
• Werdykty per pozycja. Tabela pokazująca, które pojedyncze produkty zgromadziły wystarczające dowody, aby podjąć działanie, niezależnie od wyniku ogólnego.
• Ścieżka wdrożenia po przeglądzie. Zwycięzcy trafiają do Shared Override poprzez wcześniej przejrzany snapshot. Żadne zmiany nie zostaną wprowadzone do Twojego feedu na żywo bez Twojej akceptacji.

Dlaczego istotność statystyczna ma znaczenie w testach feedu

Feedy działają w aukcji. Wolumeny ruchu wahają się w zależności od dnia tygodnia, stawek konkurencji, tempa wydawania budżetu, sezonowości oraz aktualizacji algorytmu Google. W tym kontekście różnica CTR na poziomie 4% między dwoma formatami tytułu nie stanowi dla większości katalogów istotnego sygnału.

Ludzie nadal podejmują decyzje na podstawie takich różnic. Wdrażają format tytułu na 40 000 SKU, czekają kwartał, podczas gdy wyniki dryfują, i nie wiedzą, czy to w ogóle wywołało jakikolwiek wpływ. Taka decyzja kosztuje nie tylko zmarnowany wysiłek wdrożeniowy, ale co ważniejsze — błędne założenie przenoszone do kolejnych testów.

Są tu trzy główne przyczyny błędu.

1. Odczytywanie wyniku, zanim pojawią się informacje. Zalecenia dotyczące prowadzenia dodatkowych testów feedu w optymalizacji tytułów często mówią, że 100 kliknięć to wystarczający punkt danych, aby wyciągać wnioski o trendzie. To wystarcza dla CTR. To zdecydowanie za mało, aby wyciągać jakiekolwiek wnioski o współczynniku konwersji lub ROAS — i w ten sposób większość zespołów feedowych traci pieniądze.
2. Optymalizowanie jednej metryki na gruncie innej metryki. Dopisz „Black Friday” i „Free Gift” do tytułu, a CTR wystrzeli. Jednak współczynnik konwersji i ROAS mogą spaść, ponieważ tytuł przyciągnął na stronę osoby, które nie kupują. Optymalizacja tytułu skupiona tylko na jednej metryce ogłosi tu fałszywe zwycięstwo.
3. Zatrzymywanie testu, gdy liczba wygląda dobrze. Codzienne sprawdzanie dashboardu, a następnie zatrzymanie testu, gdy tylko pojawi się wzrostowy pik, tworzy wiele fałszywych pozytywów. Wczesne wyniki liftu w teście pochodzą z losowego błądzenia. Zatrzymaj na szczycie liftu i zmierzysz szczyt liftu.

Feedoptimise dba o każdy z tych elementów jako o wbudowany element strukturalny.

Dwie metody eksperymentalne: testowanie duplikowane i rotacyjne

Ponieważ różne kanały e-commerce wiążą się z różnymi ograniczeniami w eksperymentach, Feedoptimise stosuje dwie różne metodologie testowania.

1. Duplikowane testy A/B

Podczas wykonywania eksperymentu duplikowanego Feedoptimise publikuje:

A - stary produkt, z tym samym starym ID i starymi wartościami.
B - zduplikowany produkt, z nowym przewidywalnym ID i nowymi testowanymi wartościami.

W rezultacie oba warianty mogą zbierać dane o skuteczności w tym samym czasie.

Świetne jednoczesne porównanie eksperymentu będzie dostępne, gdy miejsce docelowe akceptuje oba identyfikatory produktów i może kierować ruch do obu wersji.

Na przykład:

Stare ID: 34130964
Stary tytuł: Buty do biegania
Nowe ID: M-34130964
Nowy tytuł: Męskie lekkie buty do biegania

Oba produkty konkurują w tym samym okresie, a Feedoptimise przypisuje wyniki eksperymentu.

2. Rotacyjne testy A/B

Są miejsca docelowe, w których zduplikowane produkty nie mogą istnieć.

W takich przypadkach Feedoptimise będzie w stanie zachować to samo ID dla eksperymentu, ale rotować je między starymi i nowymi wartościami.

Pierwsza faza może używać starej wersji eksperymentu. Następnie pojawia się nowa wersja.

Feedoptimise oferuje wykonywanie rotacji albo w czasie, albo na podstawie skumulowanego wolumenu metryki (na przykład wyświetleń).

Rotacje oparte na skumulowanym wolumenie metryki są szczególnie wartościowe, ponieważ eksperyment może rotować w zależności od w przybliżeniu równej ilości zebranej ekspozycji.

Połącz eksperymenty z rzeczywistymi danymi o skuteczności

Feedoptimise łączy eksperymenty ze źródłami raportowania na poziomie pozycji, które obejmują:

Platformy reklamowe, platformy analityczne, platformy e-commerce oraz niestandardowe pliki raportowe.

W zależności od konfiguracji konta źródła raportowania mogą obejmować:

Google Ads, Google Analytics, Google Merchant Center, raportowanie Facebook/Meta, Shopify, WooCommerce, Magento, oraz niestandardowe raporty oparte na URL.

Proces podejmowania decyzji

Między „testowana linia jest wyżej” a „testowana wygrywa” leży sześć czynników.

1. Po pierwsze, z góry wybierana jest metryka główna

Wybierz metrykę odpowiadającą hipotezie: ROAS, wartość na kliknięcie, wartość na konwersję, współczynnik konwersji lub CTR. Algorytm automatycznego wyboru preferuje metryki oparte na ROAS na poziomie raportu. Wybór metryki po fakcie, która faworyzuje wariant, to sposób, w jaki zespoły sztucznie generują zwycięstwa.

Feedoptimise oblicza je na podstawie bazowych ról addytywnych. Mapowanie Twoich kolumn źródłowych odbywa się w kategoriach pięciu ról semantycznych:

Z nich silnik wyciąga CTR, współczynnik konwersji, CPC, ROAS, wartość na kliknięcie oraz wartość na konwersję. To mapowanie wielkości na liczby umożliwia przeprowadzenie poprawnego resamplingu.

2. Przedział ufności, a nie tylko jedna liczba

Przeprowadź test przez dwa tygodnie i otrzymasz jedną wartość: testowana wersja wypadła o 8% lepiej. Przeprowadź test przez kolejne dwa tygodnie, a da inną odpowiedź, ponieważ kliknięcia i konwersje nie są rozłożone równomiernie.

Feedoptimise analizuje tę niepewność. Silnik powtarza Twój test tysiące razy na Twoich rzeczywistych danych dziennych na wszystkie możliwe sposoby i daje Ci przedział, w którym może znajdować się prawdziwy lift.

Zaobserwowany lift:   +8%
95% CI:               +2% do +14%

Wszystkie wartości w tym przedziale są dodatnie, dlatego testowana wersja wygrywa.

Zaobserwowany lift:    +8%
95% CI:                -3% do +18%

Ten sam nagłówek. Ten przedział zawiera zero, więc różnica może wynosić +18% i -3%, a Twoje dane nie pozwalają Ci ich rozróżnić. Wniosek pozostaje niejednoznaczny.

Poziom ufności oznacza, jak wiarygodne są dane w potwierdzaniu określonego kierunku różnicy. Nie jest to prawdopodobieństwo zysku z wdrożenia.

3. Minimalny lift ustawiony z góry

Istotność statystyczna i istotność praktyczna to różne pojęcia. Może wystąpić lift 0,4% w ROAS, który będzie realny, ale niewystarczająco wartościowy, aby wdrażać go w całym katalogu. Domyślny minimalny lift to 5%. Standardowa surowość wymaga przekroczenia zera i minimalnego liftu. Ustawienie Strict wymaga, aby cały przedział był powyżej progu minimalnego liftu.

4. Bramki próby po obu stronach

Wartości domyślne to 5 000 wyświetleń, 300 kliknięć i 30 konwersji na każdą stronę oraz minimum 14 dni.

„Na każdą stronę” robi różnicę. Jeśli raport mówi, że masz 10 000 wyświetleń, wygląda to dobrze, dopóki nie zobaczysz, że 9 200 wyświetleń należy do oryginalnego zestawu reklam. Bramka zostanie prawidłowo utrzymana w statusie Waiting. Liczby zagregowane zaciemniają dokładnie tego typu informacje.

Bramki per pozycja działają osobno z 1 000 wyświetleń, 100 kliknięciami i 10 konwersjami na każdą stronę. Możliwe jest uzyskanie solidnego wniosku na poziomie raportu, podczas gdy większość pojedynczych SKU będzie w etapie Insufficient Data. To standardowy stan katalogu z długim ogonem.

5. Opóźnienie konwersji

Zamówienia pojawiają się po kliknięciach. Opóźnienie konwersji usuwa ostatnie dni z próby decyzyjnej, aby uwzględnić spóźnione konwersje. Wartość domyślna to siedem dni i należy ją określić w zależności od rzeczywistego opóźnienia atrybucji na Twojej platformie. Test może osiągnąć datę końcową i nadal być w statusie Waiting z powodu opóźnienia konwersji, co oznacza, że system odmawia oceny niekompletnego zestawu danych.

6. Guardraile

Guardraile kontrolują ROAS, współczynnik konwersji, CPC oraz wartość na kliknięcie podczas działania metryki głównej. Niespełnienie guardraila uniemożliwi wygraną testowanej wersji. Typowy przykład to zmiana tytułu, która zwiększa CTR o 12%, ale obniża współczynnik konwersji o 20%. Metryka główna jest w porządku, ale guardrail wykrywa problem i daje werdykt Guardrail failed zamiast Tested is winning.

Guardraile nie uniemożliwiają wygranej wersji oryginalnej. Pozostawienie tego, co już masz, nie niesie dla Ciebie dodatkowego ryzyka.

Możliwe werdykty

• Testowana wersja wygrywa
• Oryginał wygrywa
• Brak decyzji
• Zbieranie danych
• Oczekiwanie na minimalny czas trwania
• Oczekiwanie na ekspozycję
• Oczekiwanie na opóźnienie konwersji
• Guardrail niezaliczony
• Niewystarczające dane

Siedem z dziewięciu werdyktów to odmowa podjęcia decyzji. Ten stosunek jest celem. „Nie ma zwycięzcy” to prawidłowy wynik eksperymentu, a narzędzie testowe, które zawsze wyłania zwycięzcę, jest bezużyteczne.

Decyzje produktowe: które SKU faktycznie się poprawiły

Zwycięstwa produktowe nie zawsze są uniwersalne w ramach testu — bywają po prostu dodatnie w ujęciu łącznym.

Karta Product decisions analizuje poszczególne produkty oddzielnie od analizy zagregowanej, albo na poziomie parent z metrykami wariantów zrolowanymi, albo jako pary parent-original do parent-tested variant. Każdy wiersz zawiera zwycięzcę, wynik ufności, procent liftu, rzeczywiste metryki, status, ocenę guardraila oraz informację, czy kwalifikuje się jako snapshot. Wejdź w szczegóły wiersza, aby zobaczyć metryki bazowe dla oryginału i testowanej wersji, ich stosunek, konkretną bramkę używaną dla statusu oraz historię decyzji.

To właśnie tutaj odbywają się selektywne wdrożenia. Po prostu zastosuj zwycięski tytuł testowy do 340 produktów, które go wygrały, a pozostałe produkty pozostaw bez zmian.

Od werdyktu do feedu na żywo

Wygrany test nie dotyka Twojego feedu. Publikacja przebiega przez trzy kroki po przeglądzie.

1. Snapshot. Zdecyduj, które testy powinny zostać wdrożone, korzystając z Implement tested winners dla selektywnego wdrożenia, Save original winner decisions, aby zapisać, co zadziałało, lub Apply whole-report decision, jeśli eksperyment był zaplanowany jako jedna decyzja dla wszystkich.
2. Podgląd. Każde okno dialogowe snapshot najpierw wykonuje dry run. Informuje o liczbie jednostek ocenionych, zakwalifikowanych, zwycięzcach i ich statusie, jednostkach bez atrybucji oraz próbce wierszy, które zapisuje. Jednostki, które nie mogą przypisać atrybucji, nie zawierają przechwyconych wartości pola dla wybranej strony, dlatego zostaną pominięte podczas zapisywania. Przeanalizuj te wiersze przed ich zapisaniem.
3. Override. Zakwalifikowane wiersze są zapisywane w Shared Override. Zastosowanie override do feedu jest osobnym krokiem w Feed Mapping, z własnym etapem podglądu. Pozycje, których nie ma w override, zachowają swoją wartość w feedzie.

Warto wspomnieć o dwóch opcjach. Values to save jest niezależne od filtra zwycięzcy: pierwsze określa, które wiersze są kwalifikowane, a drugie — wartości której strony są zapisywane.

Każde wdrożenie jest zawsze audytowalne i można je cofnąć. W przypadku ważnego feedu użyj podglądu feedu przed wdrożeniem go w feedzie na żywo.

Feedoptimise a inne podejścia do testowania feedu

Należy zauważyć, że nie wszystkie funkcje testów A/B oferują takie same możliwości testowania.

Proces testowania feedu, który jest szeroko nagłaśniany i znany, obejmuje cztery identyczne kroki: podział produktów na segmenty, zmiana treści, zbieranie danych o skuteczności, porównanie metryk. Feedoptimise wykonuje wszystkie powyższe kroki i idzie dalej — podejmuje ostateczną decyzję.

Przestań zgadywać. Zacznij testować.

Optymalizacja feedu nie powinna kończyć się w momencie stworzenia tytułu, obrazu czy atrybutu — to tutaj zaczyna się testowanie.

Dzięki Feedoptimise A/B Testing sprzedawcy i agencje mogą testować swoje dane produktowe w zderzeniu z rzeczywistością, weryfikować, czy zmiany mają wystarczająco dużo uzasadnienia, oraz bezpiecznie przekształcać zakwalifikowanych zwycięzców w realne wygrane optymalizacji feedu.

Rozpocznij bezpłatny okres próbny lub Umów demo