חשב דלי הכנסות עבור סכימת ערך המרות ברשת SKAd

1. הקדמה

קצת הקשר לפני שנתחיל

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

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

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

דרישות מוקדמות

• GA4F SDK באפליקציית iOS שלך, וכל אירועי ההכנסה משולבים (in_app_purchase או הכנסה במימון מודעות )
• ייצוא Firebase ל-BigQuery מופעל
• App Attribution Partner, אשר גם מתעד את כל אירועי ההכנסות

2. גישה אל BigQuery Export

נווט אל מערך הנתונים של Google Cloud

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

הפעל כמה שאילתות

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

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

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

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

שואב נתוני התקנה

כעת על מנת להתחיל לבנות את דלי ההכנסות, עלינו להסתכל תחילה על נתונים עבור משתמשים שהתקינו באפליקציה במהלך 24 עד 72 השעות האחרונות. SKAd Network 4.0 מאפשר לך להציג נתונים תוך 0-2 ימים, בעוד ש-SKAd Network 3.5 מאפשר 24 שעות כברירת מחדל. (בהתאם ליכולות של שותף ייחוס האפליקציה שלך, ייתכן שתוכל לשנות את חלון הפעילות הזה בדרך כלל ללא יותר מ-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, ההכנסה זמינה בפרמטר ה-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 נמחקת כאן).

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

עד כה, הרצנו שתי שאילתות, אחת כדי למצוא את הנתונים עבור המשתמשים שהתקינו ופתחו את האפליקציה, ואחת נוספת כדי למצוא את ההכנסות עבור אותם משתמשים. כעת, בואו נזכור על מה שדיברנו על מגבלות רשת SKAd. חלון הייחוס יכול להיות זמין רק בתוך 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 דליים וביגQuery מנסה לשמור על התפלגות אחוזונים עקבית

נתח את תפוצת המשתמשים עם הדליים האלה

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

• 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

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

מילה מהירה על SKAd Network 4.0

SKAd Network 4.0 מספק חלונות המרה מרובים של עד יומיים, 3-7 ימים ו-8-35 ימים. בגישה שלמעלה, אתה יכול בקלות לשנות את החלון כדי לנתח נתונים גם עבור תרחישים נוספים אלה. זמינים גם ערכי גרעינים גסים של LOW, MEDIUM ו-HIGH. שוב, אם אתה רוצה להשתמש בגישה זו, אתה יכול לחשוב על זה כעל 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, ומודד את ההשפעה באמצעות סכימת ערך המרות ברשת SKAd

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

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

5. מזל טוב

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

למדת

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