חישוב קטגוריות הכנסה עבור הסכימה של ערכי המרות ב-SKAdNetwork

1. מבוא

קצת רקע לפני שמתחילים

מפתחי אפליקציות ל-iOS בוודאי שמעו על עדכוני הפרטיות ל-iOS 14.5 ואילך. כדי למדוד פעולות המרה משמעותיות אחרי ההתקנה, Apple מספקת את SKAd Network API, שמאפשר למדוד את הצלחת הקמפיינים הפרסומיים תוך שמירה על פרטיות המשתמשים. בהתאם לצרכים העסקיים שלכם, תוכלו למצוא את הדרך האופטימלית להשתמש ב-SKAdNetwork כדי לקבל תובנות משמעותיות לגבי הקמפיינים שלכם. ב-codelab הזה אנחנו בוחנים מתודולוגיה לדוגמה למינוף הנתונים של GA4F ב-BigQuery כדי לקבץ הכנסות אחרי התקנת האפליקציה לדליים, שאחר כך תוכלו להשתמש בהם כדי להגדיר שותף לשיוך לאפליקציה. ב-codelab הזה נעשה שימוש בגישה שמבוססת על הכנסות, אבל אפשר גם להשתמש בגישות שמבוססות על אירועים או על משפך לצורך מעקב ב-SKAN. הנחיות מפורטות יותר זמינות במרכז העזרה. זו רק דוגמה, ולא המלצה רשמית של Google. אתם יכולים לעצב סכימה משלכם בהתאם לצרכים העסקיים הספציפיים שלכם

הנושאים שנדון בהם

• סקירת נתוני GA4F ב-BigQuery
• מציאת נתוני הכנסות של משתמשים שהשלימו המרה תוך 0-2 ימים
• קיבוץ נתוני הכנסות לקטגוריות
• הבנת התפלגות המשתמשים בכל קבוצה
• הטמעה של קטגוריות ב-Appsflyer SKAN Conversion Studio

דרישות סף

• ‫GA4F SDK באפליקציית iOS, וכל אירועי ההכנסות משולבים (in_app_purchase או ad funded revenue)
• ‫Firebase to BigQuery export enabled
• שותף דוחות שיוך לקמפיינים של אפליקציה (AAP), שמתעד גם את כל אירועי ההכנסות

2. גישה ל-BigQuery Export

מעבר למערך הנתונים ב-Google Cloud

כדי לעבור אל מערך הנתונים ב-GA4F, נכנסים אל Project Settings > Integrations > BigQuery (הגדרות הפרויקט > שילובים > BigQuery). קודם צריך להפעיל את המתג, ואחרי ההפעלה חולפות כ-48 שעות עד שמערך הנתונים יהיה זמין. אפשר ללחוץ על הקישור שמופיע למטה כדי לעבור ל-BigQuery

הרצת שאילתות

עכשיו, כשאתם ב-BigQuery, אמורות להופיע הטבלאות היומיות שנוצרו. בצילום המסך לדוגמה שבהמשך, אפשר לראות 64 טבלאות יומיות, כך שהייצוא פועל כבר 64 ימים. אם אתם ניגשים לנתונים בפעם הראשונה, יכול להיות שתראו רק טבלה יומית אחת עם הנתונים של היום הקודם. בצד שמאל, מופיעה סכימת הטבלה. פרטים נוספים על השדות זמינים כאן.

כדי להתחיל לכתוב את השאילתה, אפשר ללחוץ על שאילתה > בכרטיסייה חדשה

אחר כך אפשר לנסות להריץ את השאילתה לדוגמה בכרטיסייה החדשה.

3. ניתוח נתוני הכנסות

אחזור נתוני התקנות

כדי להתחיל ליצור את קטגוריות ההכנסה, קודם צריך לבדוק את הנתונים של משתמשים שהתקינו את האפליקציה ב-24 עד 72 השעות האחרונות. ב-SKAd Network 4.0 אפשר לראות נתונים תוך 0-2 ימים, בעוד שב-SKAd Network 3.5 אפשר לראות נתונים תוך 24 שעות כברירת מחדל. (בהתאם ליכולות של השותף שלכם לשיוך המרות באפליקציות, יכול להיות שתוכלו לשנות את חלון הפעילות הזה באופן כללי כך שלא יעלה על 72 שעות). כשמשתמשים מתקינים את האפליקציה ופותחים אותה בפעם הראשונה, ה-SDK מפעיל את האירוע first_open ומתעד אותו ב-BigQuery.

המזהה שבו אפשר להשתמש ב-BigQuery הוא user_pseudo_id (שנקרא גם מזהה מופע האפליקציה), כך שאפשר להשתמש בשאילתה שלמטה כדי למצוא את המשתמשים האלה.

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'

כמה דברים שכדאי לשים לב אליהם לגבי השאילתה הזו

• צריך להחליף את שם הטבלה בטבלה שייצאתם מ-Analytics. אפשר להשתמש בתווים כלליים לחיפוש כדי לשלוח שאילתה לכמה טבלאות יומיות. לדוגמה, 2023* תבצע שאילתה בכל הנתונים בשנת 2023
• אם יש לכם הרבה משתמשים, תוכלו גם לשלוח שאילתה רק לגבי 30 הימים האחרונים כדי לקבל עיבוד מהיר יותר
• אנחנו מסננים לפי platform = ‘IOS'. אם יש לכם כמה אפליקציות ל-iOS בפרויקט Firebase, אתם יכולים גם להוסיף מסנן ל-app_info.firebase_app_id כדי לקבל נתונים של האפליקציה הספציפית

אחזור נתוני הכנסות

עכשיו נראה שאילתה למציאת נתוני ההכנסות של המשתמשים. במקרה כזה, נניח שאירועי ההכנסה שלכם הם in_app_purchase ו-ad_impression. ההכנסה מ-in_app_purchase זמינה ב-event_value_usd, ואילו ההכנסה מ-ad_impression זמינה בפרמטר value, בתוך פרמטרי האירוע. אם אתם לא מכירים את פרמטרי האירועים ב-BigQuery, מומלץ לעיין בהגדרה כאן. אתם יכולים גם לנסות את שאילתת הדוגמה הזו במאמר הרשמי שלנו, שכולל גם הסבר על חילוץ הערך מ-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')

בואו נבין מה השאילתה עושה כאן. אלה הדברים שתבחינו בהם

• בסעיף WHERE, אנחנו מסננים את אירועי ההכנסה, כי הם בלבד מעניינים אותנו, וכמו בפעם הקודמת, אנחנו מחפשים נתונים של iOS
• עכשיו, בסעיף SELECT, אנחנו לוקחים את הערך ואת המטבע של אירוע ההכנסות מפרסום (ad_impression), ואנחנו לוקחים את event_value_in_usd כשהאירוע הוא in_app_purchase
• אם אתם שולחים נתונים בכמה מטבעות, תצטרכו קודם להגדיר מטבע אחד לניתוח הזה. לצורך הדוגמה הזו, נניח שהמטבע של ההכנסות מפרסום הוא גם דולר ארה"ב

הפלט ייראה בערך כך (העמודה של user_pseudo_id מצונזרת כאן).

שילוב הנתונים האלה

עד עכשיו הפעלנו שתי שאילתות: אחת כדי למצוא את הנתונים של המשתמשים שהתקינו את האפליקציה ופתחו אותה, ועוד אחת כדי למצוא את ההכנסות מהמשתמשים האלה. עכשיו נזכיר את מה שדיברנו עליו לגבי המגבלות של SKAdNetwork. חלון השיוך יכול להיות זמין רק בטווח של 0-2 ימים אחרי ההתקנה. לכן, נצטרך לבדוק את חותמות הזמן של האירועים 'התקנה' ו'הכנסה', ולקחת את המידע רק אם הוא מתרחש בפרק הזמן הזה. עכשיו ננסה לשלב את הנתונים בשאילתה שתספק את ההכנסה הכוללת מכל פוסט יומיים אחרי התקנת האפליקציה

#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

השאילתה רק מנסה לבצע הצטרפות של נתוני ההתקנה ונתוני ההכנסות בשדה user_pseudo_id, ואז צריך לוודא חותמת הזמן היא בטווח של יומיים. אם אתם משתמשים ב-SKAd Network 3.5, ברירת המחדל היא 24 שעות, כך שאתם יכולים גם לשנות את התנאי כך שיכלול רק נתונים של יום אחד.

קיבוץ ההכנסות לקטגוריות

אחרי השאילתה הקודמת, יהיו לכם הערכים של user_pseudo_id וההכנסה הכוללת

עכשיו נצטרך לשלב את הנתונים האלה בקבוצות שאפשר להשתמש בהן לטווחים של ערכי המרות. לשם כך, נשתמש בפונקציה approx_quantiles ב-BigQuery, שיוצרת את הטווחים האלה באופן אוטומטי. לצורך הדוגמה הזו, נניח שאנחנו רוצים ליצור 5 טווחי ערכים, ולכן נשתמש בשאילתה הבאה: SELECT approx_quantiles(total_revenue, 5) AS buckets

בואו נשלב את זה בשאילתה הכללית שלנו

#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

השאילתה הזו מחלקת את ההכנסה ל-5 קטגוריות, ו-BigQuery מנסה לשמור על חלוקה עקבית של אחוזונים.

ניתוח של פיזור המשתמשים באמצעות הקטגוריות האלה

זהו שלב אופציונלי, אם רוצים להבין את התפלגות המשתמשים בכל קבוצה. בדוגמה שלנו, טווחי הדליים שמוחזרים בשאילתה הקודמת הם

• 0.1
• 0.5
• 2
• 2.5
• ‫5 [לא ייעשה שימוש בערך האחרון בתצורת הטווח]

בטווחים האחרונים, נתעלם מהדלי האחרון 5, כי בדרך כלל זה הערך המקסימלי, ואפשר פשוט להתייחס ל-2.5 כאל הטווח האחרון. הסיבה לכך היא שספקי שיוך המרות באפליקציות נוטים לחשב את ההחזר על הוצאות הפרסום באמצעות הממוצע של הטווח, ולכן צריך להחריג את הערך החריג כדי לקבל חישוב אחיד יותר.

עכשיו ננסה לבדוק את מספר המשתמשים בכל תאריך בכל הטווחים, כדי להבין את נפח המשתמשים היומי בכל קבוצה. אפשר לעשות את זה באמצעות השאילתה לדוגמה הבאה, שבה אפשר להחליף את ערכי הקבוצות בנתונים בפועל. השאילתה תיראה בערך כך:

#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

הפונקציה תחזיר את המשתמשים בכל טווח הכנסות לכל יום, כמו בדוגמה שלמטה. אם אתם רואים מספרים נמוכים מאוד בקטגוריה כלשהי או חלוקה לא אחידה באופן כללי, כדאי לשנות את מספר הקטגוריות ולהריץ מחדש את השאילתה.

הערה קצרה על SKAdNetwork 4.0

‫SKAd Network 4.0 מספק חלונות המרה מרובים של עד יומיים, 3-7 ימים ו-8-35 ימים. בגישה שלמעלה, אפשר לשנות בקלות את חלון הזמן כדי לנתח נתונים גם בתרחישים הנוספים האלה. אפשר גם להשתמש בערכים משוערים של נמוך, בינוני וגבוה. שוב, אם רוצים להשתמש בגישה הזו, אפשר לחשוב על זה כעל 3 קטגוריות. לכן, אם משנים את מספר הקטגוריות ל-3, אפשר לקבל את ערכי הסף לקטגוריות LOW,‏ MEDIUM ו-HIGH.

4. פריסה באמצעות ספק השיוך

ההנחיות האלה עשויות להשתנות בהתאם לפלטפורמה הספציפית. כדי לקבל את המידע העדכני ביותר בנושא, מומלץ לפנות לנציגים של הפלטפורמה. לצורך הדוגמה הזו, נראה איך אפשר לפרוס את הפתרון הזה ב-AppsFlyer כרגע

בשאילתה שהרצנו קודם, הטווחים הסופיים שקיבלנו כפלט היו כמו שמופיע בהמשך

• טווח 1 : 0 עד 0.1
• טווח 2 : 0.1 עד 0.5
• טווח 3 : 0.5 עד 2
• טווח 4 : 2 עד 2.5

חשוב לזכור שהחלטנו להתעלם מטווח ההכנסות האחרון, כי הוא יהיה חריג וישפיע על חישובי הממוצע של ספק השיוך של האפליקציה.

ב-AppsFlyer יש כלי שנקרא SKAN Conversion Studio, שבו אפשר להזין את הנתונים האלה ישירות בממשק המשתמש. אפשר להשתמש בגרסה 4.0 ישירות, או להשתמש במצב 'התאמה אישית' אם אתם משתמשים בגרסה 3.5, ולהוסיף מדידה של הכנסות. לאחר מכן תוכלו פשוט להוסיף את טווחי ההכנסות שחישבתם בניתוח הקודם.

שיטות מומלצות ותובנות לגבי Google Ads

אם אתם מפעילים קמפיינים ב-Google Ads ומודדים את ההשפעה באמצעות סכימה של ערכי המרות ב-SKAdNetwork, אנחנו רוצים להציע לכם כמה המלצות:

• חשוב לוודא שחלון ההמרות שבו אתם משתמשים ב-Google Ads זהה לחלון הפעילות שהגדרתם בפלטפורמה לשיוך לאפליקציות. בגרסה 3.5 של SKAdNetwork, סביר להניח שהנתונים יופיעו תוך יום עד 3 ימים, כך שתוכלו לשנות את ההגדרה בהתאם ב-Google Ads לפי השלבים שמפורטים כאן.

• אם אתם משתמשים ב-Appsflyer, כרגע מונה האירועים שמוגדר כברירת מחדל הוא 1, כלומר הוא לא מתייחס לכמה אירועים לכל משתמש. אם אתם משתמשים במודל מבוסס-אירועים למדידה ב-SKAN ומשווים אותו לקמפיינים עם יעד עלות להמרה (tCPA) ב-Google Ads, אתם יכולים לבצע התאמה אישית לפי ההנחיות האלה מ-AppsFlyer.

5. מזל טוב

הגדרתם בהצלחה את הסכימה להקצאת ערכי המרות ב-SKAdNetwork. אחרי שהתכונה תופעל, תוכלו לעקוב אחרי הנתונים בדוח SKAdNetwork ב-Google Ads כדי לבדוק את ערכי ההמרות בקמפיינים של Google Ads.

מה למדתם

• איך בודקים את הנתונים הגולמיים העשירים מ-GA4F ב-BigQuery
• גישה אנליטית לחישוב קטגוריות הכנסות לעסק
• פריסת הסכימה באמצעות AppsFlyer