3.5 KiB
Privacy Triage: iOS Day-7 Subscription Promo Pixels
Status: DRAFT — to be reviewed and submitted before ship review Asana project task: https://app.asana.com/1/137249556945/project/1202406491309510/task/1214798984829406
What pixels are being added?
Three new pixels for the day-7 existing-user promo half-sheet:
| Pixel name | When fired |
|---|---|
m_privacy-pro_existing_user_promotion_impression |
The day-7 promo half-sheet is displayed |
m_privacy-pro_existing_user_promotion_tap |
User taps the CTA ("Try It Free" / "Learn More") |
m_privacy-pro_existing_user_promotion_dismiss |
User dismisses the promo modal |
Parameters sent with each pixel
| Parameter key | Type | Value | Description |
|---|---|---|---|
appVersion |
string | e.g. 7.215.0 |
App version, added automatically |
ru |
boolean | true / false |
Whether the user is a returning user (reinstall detected via variant "ru") |
free_trial |
boolean | true / false |
Whether the user is eligible for a free trial at time of display |
No user identifiers, no browsing data, no PII.
Privacy Assessment
Is any new data collected about the user?
No new data is collected from the user. The parameters (ru, free_trial) are:
ru— derived from the install variant flag already stored locally; same parameter used bym_privacy-pro_onboarding_promotion_impressionandm_privacy-pro_skipped_onboarding_promotion_impressionfree_trial— derived from App Store product availability, already evaluated at the time of display; same parameter used by the existing promo pixels above
Does this introduce any new data collection mechanism?
No. These pixels follow the identical pattern of the pre-existing m_privacy-pro_skipped_onboarding_promotion_* pixels, which have already passed privacy triage.
Is the data linked to a user or device?
No. Pixels are sent anonymously via the standard pixel infrastructure. No user ID, device ID, or ATB is included.
What is the purpose of the data?
Measure the effectiveness of the day-7 promo half-sheet:
- Impression — how many eligible users see the promo
- Tap — conversion rate from impression to CTA click
- Dismiss — dismissal rate
This data will be used to evaluate whether the feature achieves the goal of 10 trial starts/day and to decide whether to keep the feature on.
How long is the data retained?
Standard pixel retention policy applies. Pixels are not stored on device after firing.
Are there any additional risks?
The ru parameter could theoretically indicate a user is a reinstaller, but:
- This information is already sent in the existing promo pixels
- It is aggregated data with no user-level linkage
- It is used only to segment promo performance by user cohort
Comparison to existing approved pixels
These pixels are structurally identical to m_privacy-pro_skipped_onboarding_promotion_*, which were already approved. The only differences are:
- Different pixel name (different audience segment)
- Different origin value (
funnel_modal_ios__subscriptionnudgevsfunnel_modal_ios__skippedonboardingupsell)
Open questions for privacy reviewer
- Is the
ru(returning user) parameter still acceptable given no new data is collected? - Is there any concern with the
free_trialparameter being sent on dismiss (user never tapped CTA)? - Are there any additional parameters the privacy team would like to see for monitoring purposes?