1. Introduction
Un peu de contexte avant de commencer
Si vous êtes un développeur d'applications iOS, vous devez avoir entendu parler des mises à jour de confidentialité iOS 14.5+ . Pour mesurer les actions de conversion significatives après l'installation, Apple fournit l' API SKAd Network qui vous permet de mesurer le succès de vos campagnes publicitaires tout en respectant la confidentialité des utilisateurs. En fonction des besoins de votre entreprise, vous pouvez trouver le moyen le plus optimal d'exploiter SKAd Network pour capturer des informations significatives sur vos campagnes. Dans cet atelier de programmation, nous examinons un exemple de méthodologie permettant d'exploiter vos données GA4F dans BigQuery afin de regrouper les revenus post-installation de l'application dans des compartiments, que vous pouvez ensuite utiliser pour configurer avec votre partenaire d'attribution d'application. 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 le SKAN. Veuillez vous référer à ce centre d'aide pour des conseils plus détaillés. Ceci n'est qu'un exemple, pas une recommandation officielle de Google . Vous pouvez concevoir votre propre schéma en fonction des besoins spécifiques de votre entreprise
Ce que nous avons l'intention de couvrir
- Explorer les données GA4F dans BigQuery
- Recherchez les données de revenus des utilisateurs ayant effectué une conversion dans un délai de 0 à 2 jours.
- Regrouper les données de revenus dans des compartiments
- Comprendre la répartition des utilisateurs dans chaque compartiment
- Implémentez les buckets dans Appsflyer SKAN Conversion Studio
Conditions préalables
- SDK GA4F dans votre application iOS et tous les événements de revenus intégrés (in_app_purchase ou revenus financés par la publicité )
- Exportation Firebase vers BigQuery activée
- Partenaire d'attribution d'applications, qui enregistre également tous les événements de revenus
2. Accéder à BigQuery Export
Accédez à l'ensemble de données Google Cloud
Accédez à l'ensemble de données dans GA4F en visitant Paramètres du projet > Intégrations > BigQuery. La bascule doit d'abord être activée et une fois activée, il faut environ 48 heures pour que l'ensemble de données soit disponible. Vous pouvez cliquer sur le lien ci-dessous et il vous mènera à BigQuery
Exécuter quelques requêtes
Maintenant que vous êtes dans BigQuery, vous devriez voir les tableaux quotidiens générés. Dans l'exemple de capture d'écran ci-dessous, nous voyons 64 tables quotidiennes, l'exportation est donc en cours depuis 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 de la veille. Sur la droite, vous voyez le schéma du tableau. Vous pouvez vous référer à plus de détails sur les champs ici
Afin de commencer à rédiger votre requête, vous pouvez cliquer sur Requête > Dans un nouvel onglet
Vous pouvez ensuite essayer d'exécuter l'exemple de requête dans le nouvel onglet
3. Analyser les données sur les revenus
Récupération des données d'installation
Maintenant, afin de 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 dernières 24 à 72 heures. SKAd Network 4.0 vous permet d'afficher les données en 0 à 2 jours, tandis que SKAd Network 3.5 autorise 24 heures par défaut. (En fonction des capacités de votre partenaire d'attribution d'application, vous pourrez peut-être modifier cette fenêtre d'activité en général pour ne pas dépasser 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 à propos de cette requête
- Veuillez remplacer le nom de la table par votre table Analytics exportée. Vous pouvez utiliser des caractères génériques pour interroger plusieurs tables quotidiennes. Par exemple, 2023* interrogera toutes les données de 2023.
- Si vous avez beaucoup d'utilisateurs, vous pouvez également interroger uniquement les 30 derniers jours pour un traitement plus rapide.
- Nous filtrons sur platform = 'IOS'. Si vous avez plusieurs applications iOS dans votre projet Firebase, vous pouvez également ajouter un filtre pour app_info.firebase_app_id afin d'obtenir des données pour l'application spécifique.
Récupération des données sur les revenus
Examinons maintenant une requête permettant de déterminer les revenus de vos utilisateurs. Dans ce cas, nous supposerons que vos événements de revenus sont in_app_purchase et ad_impression. Les revenus de in_app_purchase sont disponibles dans event_value_usd, tandis que pour ad_impression, les revenus sont disponibles dans le paramètre value, dans les paramètres de l'événement. Si vous n'êtes pas familier avec les paramètres d'événement dans BigQuery, nous vous recommandons de vérifier la définition ici et vous pouvez essayer cet exemple de requête dans notre référence officielle, qui couvre également l'extraction de 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')
Comprenons ce que fait la requête ici. Ce sont les choses que vous remarqueriez
- Dans la clause WHERE, nous filtrons les événements de revenus, puisque seuls ceux-ci nous intéressent, et comme la dernière fois, nous recherchons les données iOS.
- Désormais, dans la clause SELECT, nous prenons la valeur ainsi que la devise de l'événement de revenus publicitaires (ad_impression), et nous prenons 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 supposerons que la devise des revenus financés par la publicité est également l'USD.
Le résultat ressemblerait à ce qui suit (la colonne pour user_pseudo_id est rédigée ici).
La combinaison de ces données
Jusqu'à présent, nous avons exécuté deux requêtes, une pour trouver les données des utilisateurs qui ont installé et ouvert l'application, et une autre pour trouver les revenus de ces utilisateurs. Rappelons maintenant ce dont nous avons discuté sur les limitations du réseau SKAd. La fenêtre d'attribution ne peut être disponible que dans un délai de 0 à 2 jours après l'installation. Par conséquent, nous devrons vérifier les horodatages des événements pour l'installation et les revenus, et ne prendre les informations que si cela se produit dans ce laps de temps. Essayons maintenant de combiner dans une requête qui fournit le revenu total pour chaque publication 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 essaie simplement de joindre les données d'installation et les données de revenus sur le champ user_pseudo_id, puis nous devons nous assurer que l'horodatage est dans les 2 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 en tranches
Après la requête précédente, vous aurez le user_pseudo_id et le revenu total
Nous allons maintenant devoir combiner cela en compartiments que nous pouvons utiliser pour nos plages de valeurs de conversion. À cette fin, nous utiliserons la fonction approx_quantiles dans BigQuery, qui crée automatiquement ces plages pour vous. Supposons pour les besoins de cet exemple que nous souhaitons créer 5 plages, nous pouvons donc simplement utiliser SELECT approx_quantiles(total_revenue, 5) AS buckets
Sur ce, intégrons cela dans 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 5 tranches et BigQuery essaie de maintenir une répartition cohérente en centiles.
Analysez la répartition des utilisateurs avec ces buckets
Il s'agit d'une étape facultative si vous souhaitez comprendre la répartition de vos utilisateurs dans chaque compartiment. Pour notre exemple, les plages de compartiments 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 ignorerons la dernière tranche 5, car c'est généralement la valeur maximale, et nous pouvons simplement considérer 2,5 comme la dernière plage. En effet, les fournisseurs d'attribution d'applications ont tendance à calculer le ROAS en utilisant la moyenne de la plage. La valeur aberrante doit donc être exclue pour un calcul plus uniforme.
Nous allons maintenant essayer d'examiner le nombre d'utilisateurs pour chaque date sur toutes les plages, afin de pouvoir comprendre le volume quotidien d'utilisateurs dans chaque compartiment. Nous pouvons le faire en utilisant cet exemple de requête, où vous pouvez remplacer les valeurs du compartiment par vos données réelles, et la requête ressemblerait à 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 compartiment ou une distribution généralement inégale, vous souhaiterez peut-être ajuster le nombre de compartiments et réexécuter la requête.
Un petit mot sur SKAd Network 4.0
SKAd Network 4.0 offre plusieurs fenêtres de conversion allant jusqu'à 2 jours, 3 à 7 jours et 8 à 35 jours. Dans l'approche ci-dessus, vous pouvez facilement modifier la fenêtre pour analyser également les données de ces scénarios supplémentaires. Des valeurs à gros grains de FAIBLE, MOYEN et ÉLEVÉ sont également disponibles. Encore une fois, si vous souhaitez utiliser cette approche, vous pouvez considérer cela comme 3 compartiments. Ainsi, en modifiant le nombre de compartiments à 3, vous pouvez obtenir les seuils FAIBLE, MOYEN et ÉLEVÉ.
4. Déploiement avec votre fournisseur d'attribution
En fonction de la plateforme spécifique, ces instructions peuvent changer. Veuillez travailler avec les représentants de la plateforme pour obtenir les informations les plus récentes à ce sujet. Pour les besoins de cet exemple, nous verrons comment nous pouvons actuellement déployer cela 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 :
- 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 fourchette de revenus , car elle constituerait une valeur aberrante, et de fausser les calculs moyens de votre fournisseur d'attribution d'application.
AppsFlyer propose SKAN Conversion Studio , où il est assez simple de saisir cela directement dans l'interface utilisateur. Vous pouvez soit utiliser la version 4.0 directement, soit utiliser le mode « Personnalisé » si vous utilisez la version 3.5, et ajouter la mesure « Revenu ». Vous pouvez ensuite simplement ajouter les fourchettes de revenus que vous avez calculées à partir de l’analyse précédente.
Bonnes pratiques et enseignements sur Google Ads
Nous aimerions vous laisser quelques recommandations si vous diffusez des campagnes sur Google Ads et mesurez l'impact via un schéma de valeur de conversion du réseau SKAd.
- Assurez-vous que la fenêtre de conversion que vous utilisez sur Google Ads correspond à la fenêtre d'activité que vous avez spécifiée sur votre plateforme d'attribution d'application. Pour le réseau SKAd 3.5, cela prendra probablement entre 1 et 3 jours. Vous pouvez donc l'ajuster en conséquence sur Google Ads en suivant les étapes répertoriées ici .
- Si vous utilisez Appsflyer, le compteur d'événements par défaut est actuellement 1, ce qui signifie qu'il ne prend pas en compte plusieurs événements par utilisateur. Si vous utilisez un modèle basé sur des événements pour la mesure SKAN et que vous comparez avec les campagnes tCPA sur Google Ads, vous pouvez choisir de le personnaliser en suivant ces conseils d'Appsflyer.
5. Félicitations
Félicitations, vous avez configuré avec succès votre schéma de valeur de conversion réseau SKAd. Vous pouvez désormais surveiller les données de votre rapport Google Ads SKAd Network pour vérifier les valeurs de conversion de vos campagnes Google Ads une fois celles-ci en ligne.
Vous avez appris
- Comment explorer les riches données brutes de GA4F dans BigQuery
- Approche analytique pour calculer les tranches de revenus de votre entreprise
- Déployer le schéma avec AppsFlyer