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

1. מבוא

כמה הקשרים לפני שנתחיל

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

הנושאים שאנחנו מתכוונים להתייחס אליהם

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

דרישות סף

• SDK של GA4F באפליקציה ל-iOS וכל אירועי ההכנסות משולבים (in_app_purchase או הכנסות ממומנת על ידי מודעות)
• ייצוא מ-Firebase ל-BigQuery מופעל
• שותף דוחות שיוך לקמפיינים של אפליקציה (AAP) שמתעד גם את כל אירועי ההכנסה

2. גישה ל-BigQuery Export

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

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

הרצת שאילתות

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

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

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

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

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

עכשיו, כדי להתחיל ליצור את הקטגוריות של ההכנסות, אנחנו צריכים קודם לבדוק את הנתונים של המשתמשים שהתקינו את האפליקציה ב-24 עד 72 השעות האחרונות. SKAd Network 4.0 מאפשרת לכם לצפות בנתונים תוך 0 עד יומיים, ואילו SKAd Network 3.5 מאפשר 24 שעות כברירת מחדל. (בהתאם ליכולות של שותף דוחות השיוך לקמפיינים של אפליקציה (AAP), יכול להיות שתוכלו לשנות את חלון הפעילות הזה בדרך כלל ל-72 שעות לכל היותר). כשמשתמשים מתקינים את האפליקציה ופותחים אותה בפעם הראשונה, אירוע first_open מופעל על ידי ה-SDK ומתועד ב-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 הימים האחרונים כדי לזרז את העיבוד.
• אנחנו מסננים לפי פלטפורמה = 'IOS'. אם יש לכם כמה אפליקציות ל-iOS בפרויקט Firebase, תוכלו גם להוסיף מסנן עבור app_info.firebase_app_id כדי לקבל נתונים לגבי האפליקציה הספציפית.

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

עכשיו נבחן שאילתה כדי למצוא הכנסות מהמשתמשים שלכם. במקרה כזה, נניח שאירועי ההכנסה שלכם הם in_app_purchase ו-ad_impression. ההכנסה מ-in_app_purchase זמינה ב-event_value_usd, ואילו ההכנסה מ-ad_impression זמינה בפרמטר של הערך בתוך הפרמטרים של האירועים. אם אתם לא יודעים מהם פרמטרים של אירועים ב-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. חלון השיוך (Attribution) זמין רק עד 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, ואז אנחנו צריכים לוודא שחותמת הזמן היא מתוך 2 ימים. אם אתם משתמשים ב-SKAdNetwork 3.5, ברירת המחדל היא 24 שעות, כך שאפשר גם לשנות את התנאי כך שיכלול רק נתונים מיום אחד.

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

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

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

עכשיו נשלב את המידע הזה בשאילתה הכוללת שלנו

#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

ב-SKAdNetwork 4.0 יש כמה חלונות המרות של עד יומיים, 3 עד 7 ימים ו-8 עד 35 ימים. בשיטה שמתוארת למעלה, אפשר לשנות בקלות את החלון כדי לנתח נתונים גם עבור התרחישים הנוספים האלה. יש גם ערכים כלליים של נמוך, בינוני וגבוה. שוב, אם רוצים להשתמש בגישה הזו, אפשר לחשוב עליה בתור 3 קטגוריות. כך, שינוי מספר הקטגוריות ל-3 מאפשר לקבל את ערכי הסף לקטגוריות 'נמוך', 'בינוני' ו'גבוה'.

4. פריסה עם ספק השיוך (Attribution) שלכם

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

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

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

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

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

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

ריכזנו כאן כמה המלצות אם אתם מפעילים קמפיינים ב-Google Ads ומודדים את ההשפעה שלהם באמצעות סכימה של ערכי המרות ברשת SKAd.

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

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

5. מזל טוב

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

מה למדתם

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