Calculez des segments de revenus pour le schéma de valeur de conversion par réseau SKAdNetwork

1. Introduction

Informations sur le contexte avant de commencer

Si vous êtes développeur d'applications iOS, vous devez avoir entendu parler des mises à jour de confidentialité pour iOS 14.5 ou version ultérieure. Pour mesurer les actions de conversion pertinentes après l'installation, Apple fournit l'API SKAd Network, qui vous permet de mesurer l'efficacité de vos campagnes publicitaires tout en respectant la confidentialité des utilisateurs. En fonction de vos besoins commerciaux, vous pouvez trouver la manière la plus optimale d'exploiter SKAdNetwork pour obtenir des insights pertinents sur vos campagnes. Dans cet atelier de programmation, nous examinons un exemple de méthodologie permettant d'exploiter vos données GA4F dans BigQuery pour regrouper les revenus après l'installation de l'application dans des buckets, que vous pourrez ensuite configurer avec votre partenaire d'attribution d'applications. Bien que cet atelier de programmation utilise une approche basée sur les revenus, vous pouvez également utiliser des approches basées sur des événements ou des entonnoirs pour mesurer les conversions SKAN. Pour en savoir plus, consultez cet article du Centre d'aide. Il ne s'agit que d'un exemple et il ne s'agit pas d'une recommandation officielle de Google. Vous pouvez concevoir votre propre schéma en fonction de vos besoins métier spécifiques.

Points abordés

  • Explorer les données GA4F dans BigQuery
  • Obtenir les données sur les revenus des utilisateurs ayant effectué une conversion dans les 0 à 2 jours
  • Regrouper les données sur les revenus dans des buckets
  • Comprendre la répartition des utilisateurs dans chaque bucket
  • Implémenter les buckets dans Appsflyer SKAN Conversion Studio

Conditions préalables

2. Accéder à BigQuery Export

Accédez à l'ensemble de données dans GA4F en accédant à Paramètres du projet > Intégrations > dans BigQuery. Vous devez d'abord activer le bouton d'activation. Une fois cette opération effectuée, l'ensemble de données sera disponible dans un délai d'environ 48 heures. Cliquez sur le lien ci-dessous pour accéder à BigQuery.

1aa4e20bfd3419d1.png

Exécuter des requêtes

Maintenant que vous êtes dans BigQuery, les tables quotidiennes générées doivent s'afficher. Dans l'exemple ci-dessous, nous voyons 64 tableaux quotidiens. L'exportation a donc été exécutée pendant 64 jours. Si vous y accédez pour la première fois, vous ne verrez peut-être qu'un seul tableau quotidien pour les données du jour précédent. Sur la droite, le schéma de la table s'affiche. Pour en savoir plus sur les champs, cliquez ici.

Pour commencer à rédiger votre requête, cliquez sur Requête > Dans un nouvel onglet

42ba59ec655c5d1b.png

Vous pouvez ensuite essayer d'exécuter l'exemple de requête dans le nouvel onglet.

70ef90d32b7cd7f1.png

3. Analyser les données sur les revenus

Récupération des données d'installation

Pour commencer à créer des tranches de revenus, nous devons d'abord examiner les données des utilisateurs qui ont installé l'application au cours des 24 à 72 dernières heures. SKAd Network 4.0 vous permet de consulter les données sous 0 à 2 jours, tandis que SKAd Network 3.5 vous permet de le faire sous 24 heures par défaut. (selon les fonctionnalités de votre partenaire d'attribution d'applications, vous pourrez peut-être modifier cette période d'activité, généralement dans la limite de 72 heures). Lorsque les utilisateurs installent l'application et l'ouvrent pour la première fois, l'événement first_open est déclenché par le SDK et enregistré dans BigQuery.

L'identifiant que vous pouvez utiliser pour BigQuery est user_pseudo_id (également appelé ID d'instance d'application). Vous pouvez donc utiliser la requête ci-dessous pour trouver ces utilisateurs.

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'

Quelques points à noter concernant cette requête

  • Veuillez remplacer le nom de la table par votre table exportée Analytics. Vous pouvez utiliser des caractères génériques pour interroger plusieurs tables quotidiennes. Par exemple, 2023* interrogera toutes les données de l'année 2023.
  • Si vous avez beaucoup d'utilisateurs, vous pouvez également envoyer une requête portant uniquement sur les 30 derniers jours pour accélérer le traitement.
  • Nous filtrons sur "platform" = "iOS". Si votre projet Firebase comporte plusieurs applications iOS, vous pouvez également ajouter un filtre "app_info.firebase_app_id" afin d'obtenir les données de l'application spécifique.

Récupération des données sur les revenus

Examinons maintenant une requête pour trouver les revenus de vos utilisateurs. Dans ce cas, nous supposons que vos événements de revenus sont in_app_purchase et ad_impression. Les revenus générés par in_app_purchase sont disponibles dans event_value_usd, tandis que pour ad_impression, ils sont disponibles dans le paramètre "value", au sein des paramètres d'événement. Si vous ne connaissez pas les paramètres d'événement dans BigQuery, nous vous recommandons de vérifier la définition ici. Vous pouvez aussi essayer cet exemple de requête dans notre documentation de référence officielle, qui explique également comment extraire la valeur de 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')

Voyons ce que fait la requête ici. Voici les éléments que vous remarquerez :

  • Dans la clause WHERE, nous filtrons les événements de revenus, car seuls ceux qui nous intéressent. Comme la dernière fois, nous recherchons les données iOS.
  • Dans la clause SELECT, nous prenons la valeur et la devise de l'événement de revenus publicitaires (ad_impression), et nous prenons la valeur event_value_in_usd lorsque l'événement est in_app_purchase.
  • Si vous envoyez plusieurs devises, vous devez d'abord vous aligner sur une seule devise pour cette analyse. Pour les besoins de cet exemple, nous supposons que la devise des revenus financés par les annonces est également le dollar américain.

Le résultat ressemblerait à ce qui suit (la colonne pour user_pseudo_id est masquée ici).

1e1e6943e4b3a6d8.png

Combiner ces données

Jusqu'à présent, nous avons exécuté deux requêtes : l'une pour trouver les données des utilisateurs qui ont installé et ouvert l'application, et l'autre pour trouver les revenus de ces utilisateurs. Rappelons-nous ce que nous avons évoqué sur les limites du réseau SKAd. La période d'attribution ne peut être disponible que pendant 0 à 2 jours après l'installation. Nous devons donc vérifier les codes temporels des événements d'installation et de revenus, et n'utiliser les informations que si elles se produisent dans ce délai. Essayons maintenant de combiner les deux requêtes pour obtenir le revenu total pour chaque post deux jours après l'installation de l'application.

#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

La requête tente simplement de joindre les données d'installation et les données sur les revenus sur le champ user_pseudo_id. Nous devons ensuite nous assurer que le code temporel est inférieur à deux jours. Si vous utilisez SKAd Network 3.5, la valeur par défaut est de 24 heures. Vous pouvez donc également modifier la condition pour n'inclure que les données d'un jour.

Regrouper les revenus dans des catégories

Après la requête précédente, vous aurez le user_pseudo_id et le revenu total

2c1986b93e937d19.png

Nous devons maintenant regrouper ces données dans des ensembles que nous pouvons utiliser pour nos plages de valeurs de conversion. À cette fin, nous allons utiliser la fonction approx_quantiles de BigQuery, qui crée automatiquement ces plages. Supposons pour les besoins de cet exemple que nous voulons créer 5 plages, nous pouvons donc simplement utiliser SELECT approx_quantiles(total_revenue, 5) AS buckets.

Intégrons-le à notre requête globale.

#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

Cette requête doit diviser les revenus en cinq buckets, et BigQuery tente de maintenir une répartition des centiles cohérente

ba46f5d993449948.png

Analyser la répartition des utilisateurs avec ces buckets

Cette étape est facultative si vous souhaitez comprendre la répartition de vos utilisateurs dans chaque bucket. Dans notre exemple, les plages de buckets renvoyées dans la requête précédente sont

  • 0,1
  • 0,5
  • 2
  • 2.5
  • 5 [la dernière valeur ne doit pas être utilisée dans la configuration de la plage]

Pour les plages finales, nous allons ignorer le dernier segment 5, car il s'agit généralement de la valeur maximale, et nous pouvons simplement considérer 2,5 comme étant la dernière plage. En effet, les fournisseurs de solutions d'attribution d'applications ont tendance à calculer le ROAS en utilisant la moyenne de la plage. Les valeurs aberrantes doivent donc être exclues pour un calcul plus uniforme.

Nous allons maintenant essayer d'examiner le nombre d'utilisateurs pour chaque date dans toutes les plages, afin de comprendre le volume quotidien d'utilisateurs dans chaque bucket. Pour ce faire, nous pouvons utiliser cet exemple de requête, dans lequel vous pouvez remplacer les valeurs des buckets par vos données réelles. La requête ressemblera alors à ceci :

#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

Il renverra les utilisateurs dans chaque plage de revenus pour chaque jour, comme ci-dessous. Si vous constatez des nombres très faibles dans un bucket ou une distribution généralement inégale, vous pouvez ajuster le nombre de buckets et relancer la requête.

bf7d73085fe94cb6.png

Quelques mots sur SKAdNetwork 4.0

SKAdNetwork 4.0 propose plusieurs périodes de suivi des conversions de 2 jours maximum, de 3 à 7 jours et de 8 à 35 jours. Dans l'approche ci-dessus, vous pouvez facilement modifier la période d'analyse des données pour ces scénarios supplémentaires. Des valeurs à faible niveau de précision (LOW, MEDIUM et HIGH) sont également disponibles. Là encore, si vous souhaitez utiliser cette approche, vous pouvez considérer qu'il s'agit de trois buckets. Ainsi, en définissant le nombre de buckets sur trois, vous pouvez obtenir les seuils pour LOW, MEDIUM et HIGH

4. Déploiement avec votre fournisseur de solutions d'attribution

Ces consignes peuvent varier en fonction de la plate-forme. Pour en savoir plus, veuillez contacter les représentants de la plate-forme. Pour les besoins de cet exemple, nous allons voir comment déployer cette fonctionnalité sur AppsFlyer.

Dans la requête que nous avons exécutée précédemment, les plages finales que nous avons reçues en sortie étaient les suivantes :

Ba46f5d993449948.png

  • Plage 1 : 0 à 0,1
  • Plage 2 : 0,1 à 0,5
  • Plage 3 : 0.5 à 2
  • Plage 4 : 2 à 2,5

N'oubliez pas que nous avons décidé d'ignorer la dernière plage de revenus, car il s'agira d'une valeur aberrante, et que les calculs de la moyenne seront faussés pour votre fournisseur de solutions d'attribution d'applications.

AppsFlyer propose SKAN Conversion Studio, qui permet de saisir facilement cette information directement dans l'UI. Vous pouvez utiliser directement la version 4.0 ou le mode "Personnalisé" si vous utilisez la version 3.5, puis ajouter la mesure "Revenus". Il vous suffit alors d'ajouter les plages de revenus que vous avez calculées à partir de l'analyse précédente.

f8c56abdf9b405f4.png

Bonnes pratiques et enseignements sur Google Ads

Nous souhaitons vous donner quelques recommandations si vous diffusez des campagnes sur Google Ads et que vous mesurez leur impact à l'aide d'un schéma de valeur de conversion SKAdNetwork.

  • Assurez-vous que la période de suivi des conversions que vous utilisez dans Google Ads correspond à la période d'activité que vous avez spécifiée sur votre plate-forme d'attribution d'applications. Pour SKAdNetwork 3.5, ce délai est généralement d'un à trois jours. Vous pouvez donc l'ajuster en conséquence dans Google Ads en suivant les étapes décrites ici.

4fd625aae9d4a43.png

  • Si vous utilisez Appsflyer, le compteur d'événements par défaut est actuellement de 1, ce qui signifie qu'il ne prend pas en compte plusieurs événements par utilisateur. Si vous utilisez un modèle basé sur les événements pour mesurer SKAN et que vous le comparez à des campagnes au CPA cible dans Google Ads, vous pouvez choisir de le personnaliser en suivant ces conseils d'Appsflyer.

6c7a4d703567700a.png

5. Félicitations

Félicitations, vous avez bien configuré votre schéma de valeur de conversion SKAdNetwork. Vous pouvez désormais surveiller les données dans votre rapport sur le réseau SKAdNetwork Google Ads afin de vérifier les valeurs de conversion de vos campagnes Google Ads une fois qu'il est disponible.

Ce que vous avez appris

  • Explorer les données brutes riches de GA4F dans BigQuery
  • Approche analytique pour calculer les catégories de revenus de votre entreprise
  • Déployer le schéma avec AppsFlyer