Schemat wartości konwersji SKAdNetwork

1. Wprowadzenie

Kontekst sytuacji

Jeśli jesteś deweloperem aplikacji na iOS, z pewnością słyszałeś o zmianach w zasadach ochrony prywatności w systemie iOS 14.5 lub nowszym. Aby mierzyć istotne działania powodujące konwersję po instalacji, Apple udostępnia interfejs SKAdNetwork API, który umożliwia mierzenie skuteczności kampanii reklamowych przy jednoczesnym poszanowaniu prywatności użytkowników. W zależności od potrzeb firmy możesz znaleźć optymalny sposób wykorzystania SKAdNetwork do uzyskiwania przydatnych statystyk o swoich kampaniach. W tym samouczku przyjrzymy się przykładowej metodologii wykorzystania danych GA4F w BigQuery do grupowania przychodów po instalacji aplikacji w segmenty, które możesz następnie skonfigurować z partnerem ds. atrybucji aplikacji. W tym samouczku używamy podejścia opartego na przychodach, ale do pomiarów SKAN możesz też używać podejść opartych na zdarzeniach lub ścieżkach. Więcej szczegółowych wskazówek znajdziesz w tym artykule w Centrum pomocy. To tylko przykład, nie oficjalna rekomendacja Google. Możesz zaprojektować własny schemat na podstawie konkretnych potrzeb biznesowych.

Tematy, które zamierzamy omówić

• Przeglądanie danych GA4F w BigQuery
• Znajdowanie danych o przychodach użytkowników, którzy dokonali konwersji w ciągu 0–2 dni
• Grupowanie danych o przychodach w zasobnikach
• Poznawanie rozkładu użytkowników w poszczególnych grupach
• Wdrażanie przedziałów w narzędziu AppsFlyer SKAN Conversion Studio

Wymagania wstępne

• pakiet SDK GA4F w aplikacji na iOS i wszystkie zintegrowane zdarzenia związane z przychodami (in_app_purchase lub przychodami z reklam);
• Firebase do BigQuery – eksport włączony
• firmy uczestniczącej w programie App Attribution Partner, która rejestruje też wszystkie zdarzenia związane z przychodami.

2. Dostęp do BigQuery Export

Przejdź do zbioru danych Google Cloud

Otwórz zbiór danych w GA4F, klikając Ustawienia projektu > Integracje > BigQuery. Najpierw musisz włączyć przełącznik. Po włączeniu zestaw danych będzie dostępny po około 48 godzinach. Możesz kliknąć link widoczny poniżej, aby przejść do BigQuery.

Uruchamianie zapytań

W BigQuery powinny być widoczne wygenerowane tabele dzienne. Na przykładowym zrzucie ekranu poniżej widzimy 64 tabele dzienne, co oznacza, że eksportowanie trwało 64 dni. Jeśli otwierasz ją po raz pierwszy, możesz zobaczyć tylko 1 tabelę dzienną z danymi z poprzedniego dnia. Po prawej stronie zobaczysz schemat tabeli. Więcej informacji o polach znajdziesz tutaj.

Aby rozpocząć pisanie zapytania, kliknij Zapytanie > Na nowej karcie.

Następnie możesz spróbować uruchomić przykładowe zapytanie na nowej karcie.

3. Analizowanie danych o przychodach

Pobieranie danych o instalacjach

Aby rozpocząć tworzenie przedziałów przychodów, musimy najpierw przyjrzeć się danym użytkowników, którzy zainstalowali aplikację w ciągu ostatnich 24–72 godzin. SKAdNetwork 4.0 umożliwia wyświetlanie danych w okresie 0–2 dni, a SKAdNetwork 3.5 domyślnie w okresie 24 godzin. (W zależności od możliwości partnera ds. atrybucji aplikacji możesz ogólnie zmodyfikować ten przedział czasowy, ale nie może on być dłuższy niż 72 godziny). Gdy użytkownicy zainstalują aplikację i uruchomią ją po raz pierwszy, pakiet SDK wywoła zdarzenie first_open i zostanie ono zarejestrowane w BigQuery.

Identyfikatorem, którego możesz używać w BigQuery, jest user_pseudo_id (nazywany też identyfikatorem instancji aplikacji). Aby znaleźć tych użytkowników, możesz użyć poniższego zapytania.

SELECT
  user_pseudo_id,
  event_name,
  event_date,
  event_timestamp
FROM `project_name.dataset_name.events_2023*`
WHERE
  event_name = 'first_open'
  AND platform = 'IOS'

Kilka rzeczy, na które warto zwrócić uwagę w przypadku tego zapytania

• Zastąp nazwę tabeli nazwą wyeksportowanej tabeli Analytics. Aby wysyłać zapytania do wielu tabel dziennych, możesz używać symboli wieloznacznych . Na przykład zapytanie 2023* obejmie wszystkie dane z 2023 roku.
• Jeśli masz wielu użytkowników, możesz też wysłać zapytanie dotyczące tylko ostatnich 30 dni, aby przyspieszyć przetwarzanie.
• Filtrujemy według platformy = „IOS”. Jeśli w projekcie Firebase masz kilka aplikacji na iOS, możesz też dodać filtr app_info.firebase_app_id, aby uzyskać dane dotyczące konkretnej aplikacji.

Pobieranie danych o przychodach

Przyjrzyjmy się teraz zapytaniu, które pozwala znaleźć przychody generowane przez użytkowników. W tym przypadku założymy, że zdarzenia generujące przychody to in_app_purchase i ad_impression. Przychody ze zdarzenia in_app_purchase są dostępne w parametrze event_value_usd, a przychody ze zdarzenia ad_impression są dostępne w parametrze value w ramach parametrów zdarzenia. Jeśli nie znasz parametrów zdarzeń w BigQuery, zapoznaj się z ich definicją tutaj. W naszym oficjalnym dokumencie referencyjnym możesz też wypróbować to przykładowe zapytanie, które obejmuje również wyodrębnianie wartości z event_params.

SELECT
  user_pseudo_id,
  event_name,
  EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
  (
    SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
    FROM UNNEST(event_params)
    WHERE
      KEY = 'value'
      AND event_name = 'ad_impression'
  ) AS ad_funded_revenue,
  (
    SELECT value.string_value
    FROM UNNEST(event_params)
    WHERE
      KEY = 'currency'
      AND event_name = 'ad_impression'
  ) AS ad_revenue_currency,
  (
    CASE
      WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
      ELSE 0
      END) AS iap_revenue_usd,
FROM `project_name.dataset_name.events_2023*`
WHERE
  platform = 'IOS'
  AND event_name IN (
    'in_app_purchase',
    'ad_impression')

Sprawdźmy, co robi to zapytanie. Oto, co zauważysz

• W klauzuli WHERE filtrujemy zdarzenia związane z przychodami, ponieważ interesują nas tylko te zdarzenia. Podobnie jak ostatnio szukamy danych z iOS.
• W klauzuli SELECT pobieramy teraz wartość i walutę zdarzenia związanego z przychodami z reklam (ad_impression), a także wartość event_value_in_usd, gdy zdarzeniem jest in_app_purchase.
• Jeśli wysyłasz dane w wielu walutach, musisz najpierw ujednolicić walutę na potrzeby tej analizy. Na potrzeby tego przykładu zakładamy, że walutą przychodów z reklam jest też USD.

Dane wyjściowe będą podobne do tych poniżej (kolumna user_pseudo_id została tu ocenzurowana).

Łączenie tych danych

Do tej pory uruchomiliśmy 2 zapytania: jedno, aby znaleźć dane użytkowników, którzy zainstalowali i otworzyli aplikację, a drugie, aby znaleźć przychody wygenerowane przez tych użytkowników. Przypomnijmy sobie teraz, co mówiliśmy o ograniczeniach SKAdNetwork. Okno atrybucji może być dostępne tylko w ciągu 0–2 dni od instalacji. Dlatego musimy sprawdzić sygnatury czasowe zdarzeń instalacji i przychodów i uwzględnić tylko te informacje, które mieszczą się w tym przedziale czasowym. Spróbujmy teraz połączyć te informacje w zapytanie, które podaje łączne przychody z każdego posta w ciągu 2 dni od instalacji aplikacji.

#creating the install table
WITH
  install_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_date,
      event_timestamp
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      event_name = 'first_open'
      AND platform = 'IOS'
  ),
  #creating the revenue table
  revenue_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_timestamp,
      EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
      (
        SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
        FROM UNNEST(event_params)
        WHERE
          KEY = 'value'
          AND event_name = 'ad_impression'
      ) AS ad_funded_revenue,
      (
        SELECT value.string_value
        FROM UNNEST(event_params)
        WHERE
          KEY = 'currency'
          AND event_name = 'ad_impression'
      ) AS ad_revenue_currency,
      (
        CASE
          WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
          ELSE 0
          END) AS iap_revenue_usd,
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      platform = 'IOS'
      AND event_name IN (
        'in_app_purchase',
        'ad_impression')
  )
SELECT
  it.user_pseudo_id AS user_pseudo_id,
  #combine ad revenue and IAP revenue, assuming both are in same currency
  sum(ifnull(rt.iap_revenue_usd,0) + ifnull(rt.ad_funded_revenue,0)) AS total_revenue,
FROM install_table it
INNER JOIN revenue_table rt
  ON it.user_pseudo_id = rt.user_pseudo_id
WHERE
  rt.event_timestamp >= it.event_timestamp
  AND rt.event_timestamp
    <= it.event_timestamp + 86400000000 * 2  #added 86400 000 millisecond as 24 hours, taking for 2 days later
GROUP BY 1

Zapytanie próbuje połączyć dane o instalacjach i dane o przychodach w polu user_pseudo_id, a następnie musimy się upewnić, że sygnatura czasowa mieści się w zakresie 2 dni. Jeśli używasz SKAdNetwork 3.5, domyślna wartość to 24 godziny, więc możesz też zmienić warunek, aby uwzględniać tylko dane z 1 dnia.

Grupowanie przychodów w przedziały

Po wykonaniu poprzedniego zapytania uzyskasz identyfikator user_pseudo_id i łączne przychody.

Musimy teraz połączyć te wartości w przedziały, których będziemy używać w przypadku zakresów wartości konwersji. W tym celu użyjemy funkcji approx_quantiles w BigQuery, która automatycznie tworzy te zakresy. Na potrzeby tego przykładu załóżmy, że chcemy utworzyć 5 zakresów. Możemy więc użyć zapytania SELECT approx_quantiles(total_revenue, 5) AS buckets.

Włączmy to do naszego ogólnego zapytania.

#creating the install table
WITH
  install_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_date,
      event_timestamp
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      event_name = 'first_open'
      AND platform = 'IOS'
  ),
  #creating the revenue table
  revenue_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_timestamp,
      EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
      (
        SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
        FROM UNNEST(event_params)
        WHERE
          KEY = 'value'
          AND event_name = 'ad_impression'
      ) AS ad_funded_revenue,
      (
        SELECT value.string_value
        FROM UNNEST(event_params)
        WHERE
          KEY = 'currency'
          AND event_name = 'ad_impression'
      ) AS ad_revenue_currency,
      (
        CASE
          WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
          ELSE 0
          END) AS iap_revenue_usd,
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      platform = 'IOS'
      AND event_name IN (
        'in_app_purchase',
        'ad_impression')
  ),
  total_revenue_table AS (
    SELECT
      it.user_pseudo_id AS user_pseudo_id,
      #combine ad revenue and IAP revenue, assuming both are in same currency
      sum(ifnull(rt.iap_revenue_usd,0) + ifnull(rt.ad_funded_revenue,0)) AS total_revenue,
    FROM install_table it
    INNER JOIN revenue_table rt
      ON it.user_pseudo_id = rt.user_pseudo_id
    WHERE
      rt.event_timestamp >= it.event_timestamp
      AND rt.event_timestamp
        <= it.event_timestamp + 86400000000 * 2  #added 86400 000 millisecond as 24 hours
    GROUP BY 1
  )
SELECT approx_quantiles(total_revenue, 5) AS buckets FROM total_revenue_table

To zapytanie podzieli przychody na 5 przedziałów, a BigQuery spróbuje utrzymać spójny rozkład percentylowy.

Analizowanie rozkładu użytkowników w tych przedziałach

Jest to krok opcjonalny, jeśli chcesz poznać rozkład użytkowników w poszczególnych grupach. W naszym przykładzie zakresy przedziałów zwrócone w poprzednim zapytaniu to:

• 0,1
• 0,5
• 2
• 2.5
• 5 [ostatnia wartość nie powinna być używana w konfiguracji zakresu]

W przypadku ostatnich zakresów pominiemy ostatni przedział 5, ponieważ jest to zwykle wartość maksymalna, a ostatni zakres możemy uznać za 2, 5. Dzieje się tak, ponieważ dostawcy atrybucji aplikacji zwykle obliczają ROAS, używając średniej z zakresu, więc wartość odstająca musi zostać wykluczona, aby obliczenia były bardziej jednolite.

Teraz spróbujemy sprawdzić liczbę użytkowników w poszczególnych dniach we wszystkich zakresach, aby poznać dzienną liczbę użytkowników w każdym przedziale. Możemy to zrobić za pomocą tego przykładowego zapytania, w którym możesz zastąpić wartości przedziałów rzeczywistymi danymi. Zapytanie będzie wyglądać mniej więcej tak:

#creating the install table
WITH
  install_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_date,
      event_timestamp
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      event_name = 'first_open'
      AND platform = 'IOS'
  ),
  #creating the revenue table
  revenue_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_timestamp,
      EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
      (
        SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
        FROM UNNEST(event_params)
        WHERE
          KEY = 'value'
          AND event_name = 'ad_impression'
      ) AS ad_funded_revenue,
      (
        SELECT value.string_value
        FROM UNNEST(event_params)
        WHERE
          KEY = 'currency'
          AND event_name = 'ad_impression'
      ) AS ad_revenue_currency,
      (
        CASE
          WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
          ELSE 0
          END) AS iap_revenue_usd,
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      platform = 'IOS'
      AND event_name IN (
        'in_app_purchase',
        'ad_impression')
  ),
  total_revenue_table AS (
    SELECT
      it.user_pseudo_id AS user_pseudo_id,
      rt.event_date,
      #combine ad revenue and IAP revenue, assuming both are in same currency
      sum(ifnull(rt.iap_revenue_usd,0) + ifnull(rt.ad_funded_revenue,0)) AS total_revenue,
    FROM install_table it
    INNER JOIN revenue_table rt
      ON it.user_pseudo_id = rt.user_pseudo_id
    WHERE
      rt.event_timestamp >= it.event_timestamp
      AND rt.event_timestamp
        <= it.event_timestamp + 86400000000 * 2  #added 86400 000 millisecond as 24 hours
    GROUP BY 1, 2
  )
SELECT
  event_date,
  sum(CASE WHEN total_revenue BETWEEN 0 AND 0.1 THEN 1 ELSE 0 END) AS Bucket1,
  sum(CASE WHEN total_revenue BETWEEN 0.1 AND 0.5 THEN 1 ELSE 0 END) AS Bucket2,
  sum(CASE WHEN total_revenue BETWEEN 0.5 AND 2 THEN 1 ELSE 0 END) AS Bucket3,
  sum(CASE WHEN total_revenue BETWEEN 2 AND 2.5 THEN 1 ELSE 0 END) AS Bucket4,
  sum(CASE WHEN total_revenue > 2.5 THEN 1 ELSE 0 END) AS Bucket5
FROM total_revenue_table
GROUP BY 1 ORDER BY 1 DESC

Zwróci ona użytkowników w każdym zakresie przychodów w poszczególnych dniach, jak poniżej. Jeśli w którymś z przedziałów widzisz bardzo małe liczby lub ogólnie nierównomierny rozkład, możesz dostosować liczbę przedziałów i ponownie uruchomić zapytanie.

Krótko o SKAdNetwork 4.0

SKAdNetwork 4.0 udostępnia wiele okien konwersji: do 2 dni, 3–7 dni i 8–35 dni. W przypadku powyższego podejścia możesz łatwo zmienić okno, aby analizować dane również w tych dodatkowych scenariuszach. Dostępne są też wartości przybliżone NISKA, ŚREDNIA i WYSOKA. Jeśli chcesz zastosować to podejście, możesz podzielić dane na 3 grupy. Zmieniając liczbę grup na 3, możesz uzyskać progi dla wartości NISKICH, ŚREDNICH i WYSOKICH.

4. Wdrażanie z użyciem dostawcy atrybucji

W zależności od konkretnej platformy te wskazówki mogą się zmieniać. Aby uzyskać najbardziej aktualne informacje na ten temat, skontaktuj się z przedstawicielami platformy. Na potrzeby tego przykładu przyjrzymy się, jak obecnie można wdrożyć to rozwiązanie w AppsFlyer.

W zapytaniu, które zostało wcześniej uruchomione, ostateczne zakresy otrzymane jako dane wyjściowe były następujące:

• Zakres 1 : 0–0,1
• Zakres 2 : 0,1–0,5
• Zakres 3 : 0,5–2
• Zakres 4 : 2–2,5

Pamiętaj, że zignorowaliśmy ostatni zakres przychodów, ponieważ będzie on wartością odstającą i może zniekształcić obliczenia średniej wartości dla dostawcy atrybucji aplikacji.

AppsFlyer oferuje SKAN Conversion Studio, w którym można łatwo wprowadzić te dane bezpośrednio w interfejsie. Możesz używać bezpośrednio wersji 4.0 lub trybu „Niestandardowy”, jeśli używasz wersji 3.5, i dodać pomiar „Przychody”. Następnie możesz po prostu dodać zakresy przychodów obliczone na podstawie wcześniejszej analizy.

Sprawdzone metody i wskazówki dotyczące Google Ads

Jeśli prowadzisz kampanie w Google Ads i mierzysz ich skuteczność za pomocą schematu wartości konwersji SKAdNetwork, mamy dla Ciebie kilka rekomendacji.

• Upewnij się, że okno konwersji używane w Google Ads jest zgodne z oknem aktywności określonym na platformie atrybucji w aplikacji. W przypadku sieci SKAd w wersji 3.5 zwykle trwa to od 1 do 3 dni, więc możesz odpowiednio dostosować to ustawienie w Google Ads, wykonując czynności opisane tutaj.

• Jeśli korzystasz z Appsflyer, domyślny licznik zdarzeń ma obecnie wartość 1, co oznacza, że nie uwzględnia wielu zdarzeń na użytkownika. Jeśli do pomiaru SKAN używasz modelu opartego na zdarzeniach i porównujesz go z kampaniami Docelowy CPA w Google Ads, możesz dostosować go, postępując zgodnie z tymi wskazówkami od AppsFlyer.

5. Gratulacje

Gratulacje, schemat wartości konwersji SKAdNetwork został skonfigurowany. Gdy ta funkcja zostanie wdrożona, możesz monitorować dane w raporcie SKAdNetwork w Google Ads, aby sprawdzać wartości konwersji w kampaniach Google Ads.

Czego się nauczysz

• Jak eksplorować bogate dane pierwotne z GA4F w BigQuery
• Analityczne podejście do obliczania przedziałów przychodów w przypadku Twojej firmy
• Wdrażanie schematu za pomocą AppsFlyer