83 lines
3.5 KiB
Markdown
83 lines
3.5 KiB
Markdown
# 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 by `m_privacy-pro_onboarding_promotion_impression` and `m_privacy-pro_skipped_onboarding_promotion_impression`
|
|
- `free_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:
|
|
1. Different pixel name (different audience segment)
|
|
2. Different origin value (`funnel_modal_ios__subscriptionnudge` vs `funnel_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_trial` parameter being sent on dismiss (user never tapped CTA)?
|
|
- [ ] Are there any additional parameters the privacy team would like to see for monitoring purposes?
|