Tworzenie eksperymentów Zdalnej konfiguracji Firebase z Testami A/B

Gdy używasz Firebase Remote Config do wdrażania ustawień aplikacji z aktywną bazą użytkowników, musisz mieć pewność, że wszystko przebiegnie prawidłowo. Za pomocą eksperymentów A/B Testing możesz najlepiej określić:

  • Najlepszy sposób na wdrożenie funkcji optymalizującej wrażenia użytkowników. Deweloperzy aplikacji zbyt często dowiadują się, że użytkownicy nie lubią nowej funkcji lub zaktualizowanego interfejsu, dopiero gdy ocena aplikacji w sklepie z aplikacjami spadnie. A/B Testing może pomóc Ci sprawdzić, czy użytkownicy lubią nowe warianty funkcji, czy wolą aplikację w obecnej postaci. Dodatkowo utrzymywanie większości użytkowników w grupie podstawowej zapewnia, że większość użytkowników może nadal korzystać z aplikacji bez żadnych zmian w jej działaniu lub wyglądzie do czasu zakończenia eksperymentu.
  • Najlepszy sposób na optymalizację wrażeń użytkowników pod kątem celu biznesowego. Czasami wprowadzasz zmiany w produkcie, aby zmaksymalizować wartość wskaźnika, np. przychodów lub utrzymania klientów. W A/B Testing określasz cel biznesowy, a Firebase przeprowadza analizę statystyczną, aby sprawdzić, czy wariant jest skuteczniejszy od elementu bazowego w zakresie wybranego celu.

Aby przeprowadzić test A/B wariantów funkcji z wartością bazową:

  1. Utwórz eksperyment.
  2. Zarządzaj eksperymentem.

Utwórz eksperyment

Remote Config Eksperyment umożliwia ocenę wielu wariantów na podstawie co najmniej 1 Remote Configparametru.

  1. Sprawdź, czy w projekcie włączona jest usługa Google Analytics, aby eksperyment miał dostęp do danych Analytics.

    Jeśli podczas tworzenia projektu nie włączysz Google Analytics, możesz to zrobić na karcie Ustawienia > Integracje w konsoli Firebase.

  2. W konsoli Firebase otwórz DevOps i zaangażowanie > A/B Testing.

  3. Kliknij Utwórz eksperyment, a potem kliknij Remote Config, gdy pojawi się prośba o wybranie usługi, z którą chcesz przeprowadzić eksperyment.

  4. W sekcji Warianty wybierz punkt odniesienia i co najmniej 1 wariant eksperymentu. Możesz dodać co najmniej 1 parametr, który chcesz przetestować. Tę czynność możesz powtórzyć, aby dodać do eksperymentu kilka parametrów.

  5. (Opcjonalnie) Aby dodać do eksperymentu więcej niż 1 wariant, kliknij Dodaj kolejny wariant.

  6. Zmień co najmniej 1 parametr w przypadku konkretnych wariantów. Wszystkie niezmienione parametry są takie same w przypadku użytkowników, którzy nie są objęci eksperymentem.

  7. Rozwiń Wagi wariantów, aby wyświetlić lub zmienić wagę wariantu w eksperymencie. Domyślnie każdy wariant ma taką samą wagę. Pamiętaj, że nierówne rozłożenie wag może spowodować wydłużenie czasu zbierania danych oraz że nie można zmienić tych ustawień po rozpoczęciu eksperymentu.

  8. Określ kryteria kierowania dla eksperymentu, korzystając z tych warunków:Remote Config

    • Użyj ponownie istniejącego warunku: jeśli istniejący warunek w szablonie Remote Config jest już zgodny z docelowymi odbiorcami, wybierz go z listy.

    • Sprawdź kolejność oceny warunków: upewnij się, że warunki na stronie Warunki są uporządkowane w odpowiedniej kolejności priorytetów. Ponieważ funkcja Remote Config sprawdza warunki kolejno od góry do dołu, inne warunki o wyższym priorytecie mogą uniemożliwić wystarczającej liczbie użytkowników spełnienie warunku powiązanego z eksperymentem.

    • Utwórz nowy warunek: jeśli żaden z dotychczasowych warunków nie spełnia Twoich wymagań dotyczących kierowania lub jeśli wolisz zduplikować istniejący warunek (np. jeśli nie chcesz używać warunku, który jest już używany przez inne parametry), utwórz nowy warunek, wybierając najpierw aplikację, która korzysta z Twojego eksperymentu. Jeśli tworzysz osobny lub zduplikowany warunek eksperymentu, upewnij się, że ma on wyższy priorytet niż istniejący warunek. W przeciwnym razie użytkownicy najpierw spełnią istniejący warunek i żaden z nich nie zostanie uwzględniony w eksperymencie.

      Następnie możesz kierować reklamy na określony podzbiór użytkowników, klikając i i wybierając co najmniej 1 opcję z tej listy:

      • Wersja: co najmniej jedna wersja aplikacji.
      • Numer kompilacji: numer kompilacji (Apple) lub kod wersji (Android) aplikacji.
      • Platforma: co najmniej jedna platforma (iOS, Android lub internet), na którą chcesz kierować reklamy.
      • System operacyjny: kieruj reklamy na użytkowników aplikacji internetowych na podstawie systemu operacyjnego i jego wersji.
      • Przeglądarka: kierowanie na użytkowników aplikacji internetowych na podstawie przeglądarki internetowej i jej wersji.
      • Kategoria urządzenia: kierowanie na użytkowników aplikacji internetowych na podstawie tego, czy korzystają z urządzeń mobilnych czy innych.
      • Języki: co najmniej 1 język i region używane do wybierania użytkowników, którzy mogą zostać uwzględnieni w eksperymencie.
      • Kraj/region: co najmniej jeden kraj lub region, w którym wybierani są użytkownicy, którzy mają być uwzględnieni w eksperymencie.
      • Lista odbiorców użytkowników: Analytics listy odbiorców używane do kierowania na użytkowników, którzy mogą zostać włączeni do eksperymentu.
      • Właściwość użytkownika: co najmniej 1 Analytics właściwość użytkownika do wybierania użytkowników, którzy mogą zostać włączeni do eksperymentu.
      • Użytkownik w losowym procencie: kierowanie na losowo wybrany odsetek użytkowników w określonym zakresie centyli.
      • Zaimportowany segment: kieruj reklamy na użytkowników należących do niestandardowych zaimportowanych segmentów przesłanych do projektu.
      • Data/godzina: kierowanie na użytkowników na podstawie określonego przedziału dat i godzin.
      • Pierwsze uruchomienie: kieruj na użytkowników na podstawie tego, że po raz pierwszy uruchomili Twoją aplikację
      • Identyfikator instalacji: kieruj reklamy na konkretne urządzenia testowe lub instancje klientów za pomocą identyfikatorów instalacji Firebase (FID).
      • Użytkownik istnieje: kierowanie na wszystkich użytkowników we wszystkich aplikacjach w projekcie
      • Sygnał niestandardowy: kieruj reklamy na użytkowników na podstawie niestandardowych sygnałów klucz-wartość po stronie klienta przekazywanych w czasie działania programu.
  9. Ustaw Wyświetlanie:wpisz odsetek użytkowników aplikacji spełniających kryteria ustawione w sekcji Kierowanie na użytkowników, których chcesz równomiernie podzielić między punkt odniesienia a co najmniej 1 wariant w eksperymencie. Może to być dowolna wartość procentowa z zakresu od 0% do 100%. Użytkownicy są losowo przypisywani do każdego eksperymentu, w tym do zduplikowanych eksperymentów.

  10. Opcjonalnie możesz ustawić zdarzenie aktywacji, aby w eksperymencie uwzględniać tylko dane użytkowników, którzy najpierw uruchomili określone zdarzenie Analytics. Pamiętaj, że wszyscy użytkownicy spełniający parametry kierowania otrzymają Remote Config wartości eksperymentalne, ale tylko ci, u których wystąpi zdarzenie aktywujące, zostaną uwzględnieni w wynikach eksperymentu.

    Aby eksperyment był prawidłowy, upewnij się, że wybrane zdarzenie występuje po aktywowaniu przez aplikację pobranych wartości konfiguracji. Dodatkowo nie można używać tych zdarzeń, ponieważ zawsze występują one przed aktywowaniem pobranych wartości:

    • app_install
    • app_remove
    • app_update

    Wybrane przez Ciebie zdarzenie Analytics jako zdarzenie aktywacji nie może być też używane jako główne dane (ani jako dodatkowe dane) w tym samym eksperymencie. Spowoduje to błąd weryfikacji w konsoli Firebase i uniemożliwi rozpoczęcie eksperymentu.

  11. W sekcji Cele eksperymentu wybierz podstawowe dane do śledzenia i dodaj z listy wszelkie dodatkowe dane, które chcesz śledzić. Obejmują one wbudowane cele (zakupy, przychody, utrzymanie, użytkownicy bez awarii itp.), Analyticszdarzenia konwersji i inne Analyticszdarzenia. Po zakończeniu kliknij Dalej.

  12. Aby zapisać eksperyment, kliknij Zapisz. Aby rozpocząć eksperyment, musisz opublikować szablon.

W ramach jednego projektu możesz przeprowadzić maksymalnie 300 eksperymentów (w tym wdrożeń). Może to być maksymalnie 24 eksperymenty i wdrożenia, które są w toku, a pozostałe to zakończone eksperymenty.

Zarządzanie eksperymentem

Gdy utworzysz eksperyment za pomocą Remote Config, możesz go rozpocząć, monitorować jego przebieg i zwiększać liczbę użytkowników, którzy w nim uczestniczą.

Po zakończeniu eksperymentu możesz zapisać ustawienia używane przez zwycięski wariant, a następnie wdrożyć je u wszystkich użytkowników. Możesz też przeprowadzić inny eksperyment.

Edytowanie eksperymentu

  1. W sekcji DevOps & Engagement w menu nawigacyjnym Firebasekonsoli kliknij Remote Config.
  2. Kliknij kartę Testy A/B.
  3. Kliknij Trwa, a potem eksperyment, który chcesz edytować.
  4. Kliknij menu kontekstowe , a potem Edytuj uruchomiony eksperyment.
  5. Aby sprawdzić, czy Twoja aplikacja ma użytkowników, którzy zostaną uwzględnieni w eksperymencie, rozwiń szczegóły i w sekcji Kierowanie i dystrybucja sprawdź, czy wyświetla się liczba większa niż 0% (np. 1% użytkowników spełniających kryteria).

Monitorowanie eksperymentu

Po pewnym czasie działania eksperymentu możesz sprawdzić jego postępy i zobaczyć wyniki uzyskane przez użytkowników, którzy wzięli w nim udział.

  1. W sekcji DevOps & Engagement w menu nawigacyjnym Firebasekonsoli kliknij Remote Config.
  2. Kliknij kartę Testy A/B.
  3. Kliknij Uruchomione, a potem kliknij lub wyszukaj tytuł eksperymentu. Na tej stronie możesz wyświetlić różne odnotowane i modelowane statystyki dotyczące prowadzonego eksperymentu, w tym:

    • % różnicy wobec punktu odniesienia: miara poprawy wartości danego rodzaju danych w przypadku danego wariantu w porównaniu z wartością bazową. Obliczana przez porównanie zakresu wartości wariantu z zakresem wartości poziomu odniesienia.
    • Prawdopodobieństwo przekroczenia wartości podstawowej: szacowane prawdopodobieństwo, że dany wariant osiągnie lepsze wyniki niż wartość podstawowa w przypadku wybranych danych.
    • observed_metric na użytkownika: na podstawie wyników eksperymentu jest to przewidywany zakres, w którym wartość danych będzie się mieścić z biegiem czasu.
    • Łącznie observed_metric: zaobserwowana wartość skumulowana w przypadku wersji podstawowej lub wariantu. Wartość ta służy do pomiaru skuteczności każdego wariantu eksperymentu i do obliczania wzrostu, zakresu wartości, prawdopodobieństwa przekroczenia wartości podstawowejprawdopodobieństwa uzyskania najlepszych wyników. W zależności od mierzonych danych ta kolumna może być oznaczona jako „Czas trwania na użytkownika”, „Przychody na użytkownika”, „Współczynnik utrzymania” lub „Współczynnik konwersji”.
  4. Po pewnym czasie trwania eksperymentu (14 dni w przypadku Remote Config) dane na tej stronie wskazują, który wariant jest „liderem” (jeśli w ogóle). Niektórym pomiarom towarzyszy wykres słupkowy, który przedstawia dane w formacie wizualnym.

Wdrażanie eksperymentu u wszystkich użytkowników

Gdy eksperyment będzie trwać wystarczająco długo, aby można było wyłonić najlepszy wariant umożliwiający realizację Twojego celu, możesz wdrożyć go dla wszystkich użytkowników. Oznacza to, że możesz wybrać wariant, który będzie wyświetlany wszystkim użytkownikom. Możesz to zrobić także w przypadku, gdy eksperyment nie wyłoni zdecydowanego zwycięzcy.

  1. W sekcji DevOps & Engagement w menu nawigacyjnym Firebasekonsoli kliknij Remote Config.
  2. Kliknij kartę Testy A/B.
  3. Kliknij Ukończono lub Trwa, a potem eksperyment, który chcesz udostępnić wszystkim użytkownikom. Kliknij menu kontekstowe , a następnie Wdróż wariant.
  4. Aby wdrożyć eksperyment dla wszystkich użytkowników, wykonaj te czynności:
    • W przypadku eksperymentu Remote Config wybierz wariant, aby określić, które wartości parametru Remote Config należy zaktualizować. Kryteria kierowania wybrane podczas tworzenia eksperymentu zostaną dodane jako nowy warunek do Twojego szablonu, aby zapewnić wdrożenie wariantu tylko w przypadku użytkowników, na których kierowany jest dany eksperyment. Kliknij Weryfikacja ze Zdalną konfiguracją, aby przejrzeć zmiany, a następnie Opublikuj zmiany, aby zakończyć wdrożenie.

Rozwijanie eksperymentu

Jeśli zauważysz, że eksperyment nie przyciąga wystarczającej liczby użytkowników, aby A/B Testing wyłonić zwycięzcę, możesz zwiększyć jego zasięg, aby dotrzeć do większego odsetka użytkowników aplikacji.

  1. W sekcji DevOps i zaangażowanie w menu nawigacyjnym Firebase konsoli kliknij Remote Config.
  2. Kliknij kartę Testy A/B.
  3. Wybierz trwający eksperyment, który chcesz edytować.
  4. W sekcji Omówienie eksperymentu kliknij menu kontekstowe, a potem kliknij Edytuj trwający eksperyment.
  5. W oknie Kierowanie wyświetli się opcja zwiększenia odsetka użytkowników, którzy biorą udział w eksperymencie. Wybierz liczbę większą niż bieżący procent i kliknij Opublikuj. Eksperyment zostanie wdrożony w przypadku określonego przez Ciebie odsetka użytkowników.

Duplikowanie eksperymentu

  1. W sekcji DevOps i zaangażowanie w menu nawigacyjnym Firebase konsoli kliknij Remote Config.
  2. Kliknij kartę Testy A/B.
  3. Wybierz trwający lub zakończony eksperyment, który chcesz zatrzymać.
  4. Kliknij Zakończone lub Trwające, najedź wskaźnikiem myszy na eksperyment, kliknij menu kontekstowe , a potem kliknij Duplikuj eksperyment lub Zatrzymaj eksperyment.

Zatrzymywanie eksperymentu

  1. W sekcji DevOps i zaangażowanie w menu nawigacyjnym Firebase konsoli kliknij Remote Config.
  2. Kliknij kartę Testy A/B.
  3. Wybierz trwający lub zakończony eksperyment, który chcesz zatrzymać.
  4. Kliknij Zakończone lub Trwające, najedź wskaźnikiem myszy na eksperyment, kliknij menu kontekstowe , a następnie kliknij Zatrzymaj eksperyment.

Identyfikacja klienta internetowego i utrzymywanie eksperymentu

Gdy użytkownik po raz pierwszy uruchamia aplikację internetową za pomocą Firebase A/B Testing w przeglądarce, generowany jest unikalny identyfikator instalacji Firebase (FID). Ten identyfikator FID jest trwale przechowywany w IndexedDB przeglądarki, aby identyfikować instancję aplikacji w kolejnych sesjach.

Firebase A/B Testing używa identyfikatora FID do przypisywania użytkowników do wariantów eksperymentu, a Google Analytics używa go do agregowania zdarzeń, aby mierzyć i analizować zachowania użytkowników w ramach poszczególnych wariantów.

Ponieważ identyfikator FID jest przechowywany w IndexedDB, Firebase A/B Testing traktuje użytkownika jako nowego użytkownika, jeśli uzyskuje on dostęp do aplikacji z innej przeglądarki lub w oknie incognito albo jeśli wyczyści IndexedDB przeglądarki. Oznacza to, że użytkownik może być uwzględniany w różnych wersjach eksperymentu, gdy korzysta z różnych przeglądarek lub sesji przeglądania.

Kierowanie na użytkowników

Użytkowników, którzy mają być uwzględnieni w eksperymencie, możesz kierować na podstawie tych kryteriów kierowania na użytkowników.

W konsoli Firebase obsługiwane są te typy reguł: Odpowiednie funkcje są dostępne w Remote Config REST API, co zostało szczegółowo opisane w dokumentacji wyrażeń warunkowych.

Typ reguły Operatorzy Wartości Uwaga
Aplikacja == Wybierz z listy identyfikatorów aplikacji powiązanych z projektem Firebase. Gdy dodajesz aplikację do Firebase, wpisujesz identyfikator pakietu lub nazwę pakietu na Androida, które definiują atrybut udostępniany jako Identyfikator aplikacji w regułach Remote Config.

Używaj tego atrybutu w ten sposób:
  • W przypadku platform Apple: użyj identyfikatora CFBundleIdentifier aplikacji. Identyfikator pakietu możesz znaleźć na karcie Ogólne głównego miejsca docelowego aplikacji w Xcode.
  • Android: użyj parametru applicationId aplikacji. Znajdziesz go w pliku applicationId na poziomie aplikacji.build.gradle(.kts)
Wersja aplikacji W przypadku wartości tekstowych:
dokładnie pasuje,
zawiera,
nie zawiera,
zawiera wyrażenie regularne

W przypadku wartości liczbowych:
<, <=, =, !=, >, >=

Określ wersje aplikacji, na które chcesz kierować reklamy.

Zanim użyjesz tej reguły, musisz użyć reguły Identyfikator aplikacji, aby wybrać aplikację na Androida lub iOS powiązaną z projektem w Firebase.

W przypadku platform Apple: użyj CFBundleShortVersionString aplikacji.

Uwaga: upewnij się, że Twoja aplikacja na platformę Apple używa pakietu SDK Firebase na platformy Apple w wersji 6.24.0 lub nowszej, ponieważ w starszych wersjach nie jest wysyłany ciąg CFBundleShortVersionString (patrz informacje o wersji).

Android: użyj versionName aplikacji.

W przypadku tej reguły w porównaniach ciągów znaków rozróżniana jest wielkość liter. Jeśli używasz operatora dokładnie pasuje, zawiera, nie zawiera lub zawiera wyrażenie regularne, możesz wybrać wiele wartości.

Jeśli używasz operatora zawiera wyrażenie regularne, możesz tworzyć wyrażenia regularne w formacie RE2. Wyrażenie regularne może pasować do całości lub części docelowego ciągu znaków wersji. Możesz też użyć kotwic ^$, aby dopasować początek, koniec lub całość ciągu docelowego.

Numer kompilacji W przypadku wartości tekstowych:
dokładnie pasuje,
zawiera,
nie zawiera,
wyrażenie regularne

W przypadku wartości liczbowych:
=, ≠, >, ≥, <, ≤

Określ wersje aplikacji, na które chcesz kierować reklamy.

Zanim użyjesz tej reguły, musisz użyć reguły Identyfikator aplikacji, aby wybrać aplikację na Androida powiązaną z projektem w Firebase.

Ten operator jest dostępny tylko w przypadku aplikacji na urządzenia z Androidem i iOS. Odpowiada ona wartości CFBundleVersion w przypadku aplikacji na urządzenia Apple i wartości versionCode w przypadku aplikacji na Androida. W przypadku tej reguły w porównaniach ciągów znaków wielkość liter ma znaczenie.

Jeśli używasz operatora dokładnie pasuje, zawiera, nie zawiera lub zawiera wyrażenie regularne, możesz wybrać wiele wartości.

Jeśli używasz operatora zawiera wyrażenie regularne, możesz tworzyć wyrażenia regularne w formacie RE2. Wyrażenie regularne może pasować do całości lub części docelowego ciągu znaków wersji. Możesz też użyć kotwic ^$, aby dopasować początek, koniec lub całość ciągu docelowego.

Platforma == iOS
Android
Sieć
 
System operacyjny ==

Określ systemy operacyjne, na które chcesz kierować reklamy.

Zanim użyjesz tej reguły, musisz użyć reguły Identyfikator aplikacji, aby wybrać aplikację internetową powiązaną z projektem w Firebase.

W przypadku danej instancji aplikacji internetowej ta reguła przyjmuje wartość true, jeśli system operacyjny i jego wersja są zgodne z wartością docelową na określonej liście.
Przeglądarka ==

Określ przeglądarki, na które chcesz kierować reklamy.

Zanim użyjesz tej reguły, musisz użyć reguły Identyfikator aplikacji, aby wybrać aplikację internetową powiązaną z projektem w Firebase.

W przypadku danej instancji aplikacji internetowej ta reguła przyjmuje wartość true, jeśli przeglądarka i jej wersja są zgodne z wartością docelową na określonej liście.
Kategoria urządzenia jest, nie jest komórka Ta reguła sprawdza, czy urządzenie, które uzyskuje dostęp do Twojej aplikacji internetowej, jest urządzeniem mobilnym czy nie (komputerem lub konsolą). Ten typ reguły jest dostępny tylko w przypadku aplikacji internetowych.
Języki zawiera się w Wybierz co najmniej 1 język. W przypadku danej instancji aplikacji ta reguła przyjmuje wartość true, jeśli jest ona zainstalowana na urządzeniu, które używa jednego z wymienionych języków.
Kraj/region zawiera się w Wybierz co najmniej 1 region lub kraj. Ta reguła przyjmuje wartość true w przypadku danej instancji aplikacji, jeśli znajduje się ona w którymś z wymienionych regionów lub krajów. Kod kraju urządzenia jest określany na podstawie adresu IP urządzenia w żądaniu lub kodu kraju określonego przez Firebase Analytics (jeśli dane Analytics są udostępniane Firebase).
Odbiorcy Zawiera przynajmniej jeden Wybierz co najmniej 1 z list Google Analytics odbiorców skonfigurowanych w projekcie.

Ta reguła wymaga reguły identyfikatora aplikacji, aby wybrać aplikację powiązaną z Twoim projektem w Firebase.

Uwaga: ponieważ wiele Analytics list odbiorców jest definiowanych przez zdarzenia lub właściwości użytkownika, które mogą być oparte na działaniach użytkowników aplikacji, zastosowanie reguły Użytkownik na liście odbiorców w przypadku danej instancji aplikacji może zająć trochę czasu. Oznacza to, że nawet jeśli użytkownik technicznie kwalifikuje się do listy odbiorców, ale Analytics nie dodał go jeszcze do tej listy w momencie wykonania fetchAndActivate(), nie będzie on spełniać warunku.

Właściwość użytkownika W przypadku wartości tekstowych:
zawiera,
nie zawiera,
dokładnie pasuje,
zawiera wyrażenie regularne

W przypadku wartości liczbowych:
=, ≠, >, ≥, <, ≤

Uwaga: w przypadku właściwości użytkownika w kliencie można ustawić tylko wartości tekstowe. W przypadku warunków, które używają operatorów numerycznych, Remote Config przekształca wartość odpowiedniej właściwości użytkownika w liczbę całkowitą lub zmiennoprzecinkową.
Wybierz z listy dostępnych Google Analyticsatrybutów użytkownika. Aby dowiedzieć się, jak używać właściwości użytkownika do dostosowywania aplikacji pod kątem bardzo konkretnych segmentów użytkowników, przeczytaj artykuł Remote Config i właściwości użytkownika.

Więcej informacji o właściwościach użytkownika znajdziesz w tych przewodnikach:

Jeśli używasz operatora dokładnie pasuje, zawiera, nie zawiera lub zawiera wyrażenie regularne, możesz wybrać wiele wartości.

Jeśli używasz operatora zawiera wyrażenie regularne, możesz tworzyć wyrażenia regularne w formacie RE2. Wyrażenie regularne może pasować do całości lub części docelowego ciągu znaków wersji. Możesz też użyć kotwic ^$, aby dopasować początek, koniec lub całość ciągu docelowego.

Uwaga: właściwości użytkownika zbierane automatycznie nie są dostępne podczas tworzenia warunków Remote Config.
Użytkownik w losowym procencie Suwak (w konsoli Firebase). Interfejs API REST używa operatorów <=, >between. 0-100

Użyj tego pola, aby zastosować zmianę do losowej próbki instancji aplikacji (o rozmiarach próbki nawet 0,0001%), używając widżetu suwaka do podzielenia losowo przetasowanych użytkowników (instancji aplikacji) na grupy.

Każda instancja aplikacji jest trwale przypisana do losowej liczby całkowitej lub ułamkowej zgodnie z wartością początkową zdefiniowaną w danym projekcie.

Reguła będzie używać domyślnego klucza (w konsoli Firebase wyświetlanego jako Edytuj wartość początkową), chyba że zmodyfikujesz wartość początkową. Aby przywrócić domyślny klucz reguły, wyczyść pole Seed.

Aby w spójny sposób kierować reklamy na te same instancje aplikacji w określonych zakresach procentowych, używaj tej samej wartości początkowej we wszystkich warunkach. Możesz też wybrać nową, losowo przypisaną grupę instancji aplikacji w określonym zakresie procentowym, podając nowy klucz.

Aby na przykład utworzyć 2 powiązane warunki, z których każdy będzie dotyczyć niepokrywających się 5% użytkowników aplikacji, możesz skonfigurować jeden warunek tak, aby pasował do odsetka z zakresu od 0% do 5%, a drugi – do zakresu od 5% do 10%. Aby umożliwić niektórym użytkownikom losowe pojawianie się w obu grupach, użyj różnych wartości początkowych dla reguł w każdym warunku.

Zaimportowany segment zawiera się w Wybierz co najmniej 1 zaimportowany segment. Ta reguła wymaga skonfigurowania niestandardowych importowanych segmentów.
Data/godzina Przed, po Określona data i godzina w strefie czasowej urządzenia lub w określonej strefie czasowej, np. „(GMT+11) czas w Sydney”. Porównuje bieżący czas z czasem pobierania danych z urządzenia.
Pierwsze uruchomienie Przed, po

Kieruj na użytkowników na podstawie tego, że po raz pierwszy uruchomili Twoją aplikację:

  • Wybierz Nowi użytkownicy, aby kierować reklamy na użytkowników, którzy po raz pierwszy otworzą Twoją aplikację po określonej dacie i godzinie w przyszłości.
  • Kliknij Zakres czasu, aby kierować reklamy na użytkowników, którzy po raz pierwszy uruchomili Twoją aplikację w zakresie przed lub po określonej dacie i godzinie. Połącz warunki PrzedPo, aby kierować reklamy na użytkowników w określonym przedziale czasu.

Kierowanie na użytkowników według pierwszego uruchomienia jest dostępne po wybraniu aplikacji na Androida, iOS lub aplikacji internetowej.

Wymagane pakiety SDK:

  • Pakiet SDK Firebase na platformę Google Analytics
  • Pakiet SDK na platformy Apple w wersji 9.0.0 lub nowszej albo Android SDK w wersji 21.1.1 lub nowszej (Firebase BoM 30.3.0 lub nowszej) oraz pakiet JavaScript SDK w wersji 12.8.0 lub nowszej.

Analytics musi być też włączone na urządzeniu klienta podczas zdarzenia polegającego na pierwszym uruchomieniu aplikacji.

Identyfikator instalacji zawiera się w Podaj co najmniej 1 identyfikator instalacji (maksymalnie 50), na który chcesz kierować reklamy. Ta reguła przyjmuje wartość true w przypadku danej instalacji, jeśli jej identyfikator znajduje się na liście wartości rozdzielonych przecinkami.

Informacje o tym, jak uzyskać identyfikatory instalacji, znajdziesz w artykule Pobieranie identyfikatorów klientów.
Użytkownik istnieje (brak operatora) Kierowanie do wszystkich użytkowników wszystkich aplikacji w bieżącym projekcie.

Użyj tej reguły warunku, aby dopasować wszystkich użytkowników w projekcie, niezależnie od aplikacji lub platformy.

Sygnał niestandardowy W przypadku wartości tekstowych:
zawiera,
nie zawiera,
dokładnie pasuje,
zawiera wyrażenie regularne

W przypadku wartości liczbowych:
=, ≠, >, ≥, <, ≤

W przypadku wartości wersji:
=, ≠, >, ≥, <, ≤

W przypadku tej reguły w porównaniach ciągów znaków rozróżniana jest wielkość liter. Jeśli używasz operatora „pasuje dokładnie”, „zawiera”, „nie zawiera” lub „zawiera wyrażenie regularne”, możesz wybrać wiele wartości. Jeśli używasz operatora „zawiera wyrażenie regularne”, możesz tworzyć wyrażenia regularne w formacie RE2. Wyrażenie regularne może pasować do całości lub części docelowego ciągu znaków wersji. Możesz też użyć kotwic ^ i $, aby dopasować początek, koniec lub całość ciągu docelowego.

W przypadku środowisk klienta obsługiwane są te typy danych:
  • iOS: int, double
  • Android: int, long, double
  • Internet: liczba

Liczba reprezentująca numery wersji, które mają być dopasowane (np. 2.1.0).

Więcej informacji o warunkach sygnałów niestandardowych i wyrażeniach warunkowych znajdziesz w sekcjach Warunki sygnałów niestandardowychElementy używane do tworzenia warunków.

A/B Testing wskaźnika

Podczas tworzenia eksperymentu wybierasz podstawowe dane, czyli cel, które będą używane do określania zwycięskiego wariantu. Warto też śledzić inne dane, aby lepiej poznać skuteczność poszczególnych wariantów eksperymentu i obserwować ważne trendy, które mogą się różnić w zależności od wariantu, np. utrzymanie użytkowników, stabilność aplikacji i przychody z zakupów w aplikacji. W eksperymencie możesz śledzić maksymalnie 5 wskaźników niezwiązanych z celem.

Załóżmy na przykład, że używasz Remote Config, aby uruchomić w aplikacji 2 różne ścieżki gry i chcesz optymalizować ją pod kątem zakupów w aplikacji i przychodów z reklam, ale chcesz też śledzić stabilność i utrzymanie użytkowników w przypadku każdego wariantu. W takim przypadku możesz wybrać jako dane celu Szacunkowe łączne przychody, ponieważ obejmują one przychody z zakupów w aplikacji i z reklam. Następnie w sekcji Inne dane do śledzenia możesz dodać te dane:

  • Aby śledzić dzienne i tygodniowe utrzymanie użytkowników, dodaj Utrzymanie (2–3 dni)Utrzymanie (4–7 dni).
  • Aby porównać stabilność w przypadku 2 ścieżek rozgrywki, dodaj Użytkownicy, u których nie wystąpiła awaria.
  • Aby wyświetlić bardziej szczegółowe widoki każdego typu przychodów, dodaj przychody z zakupówszacunkowe przychody z reklam.

W tabelach poniżej znajdziesz szczegółowe informacje o tym, jak obliczane są dane dotyczące celów i inne dane.

Dane celów

Wskaźnik Opis
Użytkownicy, u których nie wystąpił błąd Odsetek użytkowników, u których w aplikacji nie wystąpiły błędy wykryte przez pakiet SDK Firebase Crashlytics podczas eksperymentu.

Uwaga: Firebase Crashlytics nie jest obsługiwany w przypadku aplikacji internetowych.

Szacunkowe przychody z reklam Szacunkowe zarobki z reklam.
Szacunkowe łączne przychody Łączna wartość zakupu i szacunkowych przychodów z reklam.
Przychody z zakupów Łączna wartość wszystkich zdarzeń purchasein_app_purchase.
Utrzymanie użytkowników (1 dzień) Liczba użytkowników, którzy codziennie wracają do Twojej aplikacji.
Utrzymanie (2–3 dni) Liczba użytkowników, którzy wracają do Twojej aplikacji w ciągu 2–3 dni.
Utrzymanie (4–7 dni) Liczba użytkowników, którzy wracają do Twojej aplikacji w ciągu 4–7 dni.
Utrzymanie (8–14 dni) Liczba użytkowników, którzy wracają do aplikacji w ciągu 8–14 dni.
Utrzymanie użytkowników (15 dni lub więcej) Liczba użytkowników, którzy wracają do aplikacji po co najmniej 15 dniach od ostatniego użycia.
first_open To Analytics zdarzenie jest wywoływane, gdy użytkownik po raz pierwszy otwiera aplikację po jej zainstalowaniu lub ponownym zainstalowaniu. Używane w ramach ścieżki konwersji.

Inne wskaźniki

Wskaźnik Opis
notification_dismiss Analytics Zdarzenie wywoływane, gdy powiadomienie wysłane przez kompozytor powiadomień zostanie odrzucone (tylko na Androidzie).
notification_receive Analytics Zdarzenie wywoływane, gdy powiadomienie wysłane przez kompozytor powiadomień nadejdzie podczas działania aplikacji w tle (tylko na Androidzie).
os_update Analytics zdarzenie, które śledzi, kiedy system operacyjny urządzenia jest aktualizowany do nowej wersji.Więcej informacji znajdziesz w artykule Automatycznie zbierane zdarzenia.

Ten rodzaj danych nie jest obsługiwany w przypadku aplikacji internetowych.

screen_view Analytics zdarzenie, które śledzi wyświetlenia ekranów w aplikacji. Więcej informacji znajdziesz w artykule Śledzenie wyświetleń ekranu.
session_start Analytics Zdarzenie, które zlicza sesje użytkowników w aplikacji. Więcej informacji znajdziesz w artykule Zdarzenia zbierane automatycznie.

Eksportowanie danych z BigQuery

Oprócz wyświetlania A/B Testingdanych eksperymentu w konsoliFirebase możesz sprawdzać i analizować dane eksperymentu w BigQuery. A/B Testing nie ma osobnej tabeli, BigQuery ale informacje o eksperymentach i wariantach są przechowywane w każdymGoogle Analytics zdarzeniu w Analytics tabelach zdarzeń.

Właściwości użytkownika, które zawierają informacje o eksperymencie, mają postać userProperty.key like "firebase_exp_%" lub userProperty.key = "firebase_exp_01", gdzie 01 to identyfikator eksperymentu, a userProperty.value.string_value zawiera indeks (liczony od zera) wariantu eksperymentu.

Za pomocą tych właściwości użytkownika eksperymentu możesz wyodrębniać dane eksperymentu. Dzięki temu możesz analizować wyniki eksperymentu na wiele różnych sposobów i niezależnie weryfikować wyniki A/B Testing.

Aby rozpocząć, wykonaj te czynności zgodnie z opisem w tym przewodniku:

  1. Włącz eksportowanie BigQuery na potrzeby Google Analytics w konsoli Firebase
  2. Dostęp do danych A/B Testing za pomocą BigQuery
  3. Przykładowe zapytania

Włączanie eksportowania BigQuery dla Google Analytics w konsoli Firebase

Jeśli korzystasz z abonamentu Spark, możesz używać BigQuerypiaskownicy, aby uzyskać dostęp do BigQuerybezpłatnie, z zastrzeżeniem limitów piaskownicy. Więcej informacji znajdziesz w sekcji Ceny i BigQuery sandbox.

Najpierw upewnij się, że eksportujesz dane Analytics doBigQuery:

  1. W konsoli Firebase otwórz Ustawienia > kartę Integracje.

  2. Na karcie BigQuery kliknij Zarządzaj i sprawdź, czy projekt eksportuje dane Analytics do BigQuery.

    Jeśli na karcie widnieje napis Połącz, musisz skonfigurować eksport (przejdź do następnego kroku).

  3. Jeśli musisz skonfigurować eksport:

    1. Zapoznaj się z informacjami w sekcji Informacje o łączeniu Firebase z BigQuery, a potem kliknij Dalej.

    2. W sekcji Skonfiguruj integrację włącz Google Analytics.

    3. Wybierz region i ustawienia eksportu.

    4. Kliknij Połącz z BigQuery.

W zależności od wybranego sposobu eksportowania danych udostępnienie tabel może potrwać do 1 dnia. Więcej informacji o eksportowaniu danych projektu do BigQuery znajdziesz w artykule Eksportowanie danych projektu do BigQuery.

Dostęp do danych A/B Testing w usłudze BigQuery

Zanim wyślesz zapytanie o dane dotyczące konkretnego eksperymentu, musisz uzyskać niektóre lub wszystkie z tych informacji, aby użyć ich w zapytaniu:

  • Identyfikator eksperymentu: możesz go uzyskać z adresu URL strony Przegląd eksperymentu. Jeśli na przykład Twój adres URL wygląda tak:https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25, identyfikator eksperymentu to 25.
  • Google Analytics identyfikator usługi: to 9-cyfrowy Google Analytics identyfikator usługi. Znajdziesz go w sekcji Google Analytics. Pojawia się też w sekcji BigQuery po rozwinięciu nazwy projektu, aby wyświetlić nazwę tabeli zdarzeń Google Analytics (project_name.analytics_000000000.events).
  • Data eksperymentu: aby utworzyć szybsze i wydajniejsze zapytanie, warto ograniczyć je do Google Analytics partycji tabeli zdarzeń dziennych, które zawierają dane eksperymentu. Są to tabele oznaczone sufiksem YYYYMMDD. Jeśli więc eksperyment był prowadzony od 2 lutego 2024 r. do 2 maja 2024 r., musisz podać _TABLE_SUFFIX between '20240202' AND '20240502'. Przykład znajdziesz w artykule Wybieranie wartości konkretnego eksperymentu.
  • Nazwy zdarzeń: zwykle odpowiadają one danym celu skonfigurowanym w eksperymencie. Na przykład in_app_purchasewydarzenia, ad_impression lub user_retention wydarzenia.
.

Po zebraniu informacji potrzebnych do wygenerowania zapytania:

  1. W konsoli Google Cloud otwórz BigQuery.
  2. Wybierz projekt, a następnie kliknij Utwórz zapytanie SQL.
  3. Dodaj zapytanie. Przykładowe zapytania znajdziesz w artykule Przykładowe zapytania.
  4. Kliknij Wykonaj.

Tworzenie zapytań o dane eksperymentu za pomocą automatycznie generowanego zapytania w konsoli Firebase

Jeśli korzystasz z abonamentu Blaze, na stronie Przegląd eksperymentu znajdziesz przykładowe zapytanie, które zwraca nazwę eksperymentu, warianty, nazwy zdarzeń i liczbę zdarzeń w eksperymencie, który wyświetlasz.

Aby uzyskać i uruchomić automatycznie wygenerowane zapytanie:

  1. W konsoli Firebase otwórz DevOps i zaangażowanie > Testy A/B.
  2. Wybierz eksperyment A/B Testing, o który chcesz wysłać zapytanie, aby otworzyć Przegląd eksperymentu.
  3. W menu Opcje w sekcji Integracja z BigQuery wybierz Dane eksperymentu dotyczące zapytania. Spowoduje to otwarcie projektu w BigQueryGoogle Cloudkonsoli i udostępnienie podstawowego zapytania, którego możesz użyć do wysyłania zapytań o dane eksperymentu.

Poniższy przykład pokazuje wygenerowane zapytanie dotyczące eksperymentu z 3 wariantami (w tym z elementem bazowym) o nazwie „Eksperyment z zimowym powitaniem”. Zawiera nazwę aktywnego eksperymentu, nazwę wariantu, unikalne zdarzenie i liczbę zdarzeń dla każdego zdarzenia. Pamiętaj, że w nazwie tabeli narzędzie do tworzenia zapytań nie podaje nazwy projektu, ponieważ otwiera się bezpośrednio w projekcie.

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

Więcej przykładów zapytań znajdziesz w artykule Przykładowe zapytania.

Przykładowe zapytania

W sekcjach poniżej znajdziesz przykłady zapytań, których możesz używać do wyodrębniania A/B Testing danych eksperymentu z tabel zdarzeń Google Analytics.

Wyodrębnianie wartości odchylenia standardowego zakupu i eksperymentu ze wszystkich eksperymentów

Dane z wynikami eksperymentu możesz wykorzystać do niezależnego weryfikowaniaFirebase A/B Testing wyników. Poniższe BigQueryinstrukcje SQL wyodrębniają warianty eksperymentu, liczbę unikalnych użytkowników w każdym wariancie i sumują łączne przychody ze zdarzeń in_app_purchaseecommerce_purchase oraz odchylenia standardowe wszystkich eksperymentów w zakresie czasu określonym jako daty rozpoczęcia i zakończenia _TABLE_SUFFIX. Dane uzyskane z tego zapytania możesz wykorzystać w generatorze istotności statystycznej dla testów t-Studenta jednostronnych, aby sprawdzić, czy wyniki podawane przez Firebase są zgodne z Twoją analizą.

Więcej informacji o sposobie obliczania wnioskowania przez A/B Testing znajdziesz w artykule Interpretowanie wyników testów.

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

Wybierz wartości konkretnego eksperymentu

Poniższy przykład zapytania pokazuje, jak uzyskać dane dotyczące konkretnego eksperymentu w BigQuery. To przykładowe zapytanie zwraca nazwę eksperymentu, nazwy wariantów (w tym wariant podstawowy), nazwy zdarzeń i liczbę zdarzeń.

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName