TL;DR I identified an opportunity to productize TikTok's manual promotion workflow and expand it beyond a single vertical into a platform-level capability. I co-wrote the PRD with PM, defined the cross-vertical framework architecture, drove alignment across Sales Engineering, vertical PMs, and Ads Core, and recommended the campaign-level approach over ad group-level. The design followed from that foundation. The Promotion Framework shipped for Key Account advertisers across App and Entertainment verticals, replacing a fully manual SE workflow that required 20+ tool configurations per campaign and 2 hours of engineer time per client, with a clear path to GA across any vertical with a promotion scenario.
The opportunity
TikTok's Entertainment team had a manual promotion workflow for theatrical releases and streaming events. It worked, but it was entirely SE-driven — no advertiser visibility, no automated exit, and a 30-minute configuration time per client that capped how many clients could be covered during any peak event.
I noticed the underlying problem was not unique to Entertainment. Any vertical running a time-bound tentpole event — a game launch, a FIFA World Cup betting window, a flash sale — had the same need: a way to tell the platform this campaign is different, treat it accordingly. There was no productized way to do that across TikTok Ads Manager. The vision was a platform-level capability any advertiser could eventually access. I brought that to PM and we built the case together.
The problem
The manual workflow was failing in three ways. First, SE capacity was the ceiling. Configuring 20+ backend tools per campaign at 30 minutes per client meant that during high-volume events, coverage was limited by headcount. Uncovered clients underperformed, and that was a direct revenue loss.
Second, failures during promotion windows were irreversible. Tool status was checked per client, per tool, with no global view. A silent failure on launch day had no recovery path.
Third, advertisers were completely in the dark. No visibility into promotion status, active tools, or optimization state. No automatic exit when the window closed meant config leakage that caused CPA spikes post-promotion.
Underneath all of this was a scalability problem. Vertical playbooks lived in scattered docs with no shared structure. Every new vertical that wanted promotion support had to be manually onboarded with no reuse across the system.
Defining the framework
The core work was not the UI. It was defining how a promotion system could scale across verticals without requiring a custom engineering effort each time.
I built the framework around one principle: each promotion scenario maps to a predefined bundle of backend strategies. Vertical teams provide the KPI, the advertiser-facing benefit language, and the frontend defaults. The backend optimizations are never surfaced directly. This separation meant the system could scale horizontally — a new vertical adds a scenario profile, not a new product.
The flow reflects this: allowlisted clients access the Promotion Scenario Module at the campaign level, select their scenario, set a promotion schedule, and the backend auto-applies the right optimization bundle based on promotion type — aggressive or moderate — without any manual SE involvement.
The table below shows how that maps in practice.
| Vertical | Scenario | Advertiser benefit | Backend bundle |
|---|---|---|---|
| Entertainment | New title launchTheatrical / streaming · CTR / CVR | Maximize awareness and conversion during the high-interest launch window | VTA 0s24h, Swing User Boost, IMDB Boost, Cost Cap tuning |
| Gaming | Title launchGo-live + review wave · CPP | Cost per conversion efficiency at peak interest and on positive review spikes | Budget Pacing Exempt, DDB Exempt, Cypher Reserve + Recall Boost |
| Any vertical | Aggressive promotionHigh-urgency · Budget utilization | Maximum delivery during the promotion window. Trades cost efficiency for volume. | SKOverlay 1S, Budget Pacing Exempt, Smart Bid Capper Exempt |
| Any vertical | Moderate promotionCost-sensitive · CPA / tROAS | Incremental efficiency gains during the promotion window while maintaining cost controls | App tROAS, Cost Cap min budget, Cypher Reserve + Recall Boost |
Stakeholder alignment
Getting this built required aligning teams with different incentives. Sales Engineering needed to trust that automated tooling would match their manual configuration quality. Vertical PMs needed a clear onboarding path that did not require a full engineering engagement for each new scenario. Ads Core had eligibility thresholds that gated traffic support. And the business case for expanding beyond Entertainment had to be made to PM before any resources were committed.
I co-wrote the PRD with PM to build that case. The framing that got traction was opportunity sizing: 300 advertisers in the MVP cohort, 6 campaigns per year each, at 2 hours of SE time per client — 3,600 SE hours in the MVP alone. At 10 verticals and 50 clients each, that reaches 4,000 to 8,000 hours annually. The argument was not about UX. It was about SE capacity being the constraint on revenue growth during peak events.
Getting SE buy-in required demonstrating reliability. The success metric we aligned on — tool activation coverage from ~70% to ~100% — gave SE a measurable bar to hold the system to before they would hand over configuration. That single number turned a trust question into a testable one.
A key decision
The most consequential discussion was where to place the scenario toggle: campaign level or ad group level. There was a real case for ad group-level since the promotion schedule lives there and contextual proximity matters. I drove the recommendation for campaign-level for three reasons.
- Budget integrity. A tentpole event comes with a non-negotiable budget. At the campaign level, the backend can safely boost the entire CBO pool in the final 48 hours. At the ad group level the boost has to be calculated across multiple separate budgets — if one underperforms, the boost is wasted.
- Clean reporting. Advertisers need to isolate event spend from evergreen spend. Campaign-level selection makes that a single dashboard filter. Ad group-level requires manual subtraction within the same campaign and creates reporting errors that erode client trust.
- Learning Phase protection. Mixing a time-sensitive promotion ad group with slow-burn evergreen ads in the same campaign causes the algorithm to starve the promotion ads of impressions. A dedicated campaign gives the algorithm a clean slate and a focused signal.
The design
The entry point was stable throughout — a Promotion Scenario Module surfaced after objective selection, optional so it would not block new user activation. The design work was largely about simplification: taking a system with 20+ manual backend tools and reducing the advertiser experience to a single scenario selection, a promotion schedule, and auto-populated defaults.
The guiding principle was that backend complexity should be invisible to the advertiser. The system communicates expected benefits, not tooling. An advertiser running a game launch does not need to know about Cypher Reserve and Recall Boost. They need to know that selecting this scenario will maximize cost per conversion efficiency during their launch window.
Outcomes
The Promotion Framework shipped with a KA allowlist as the MVP entry point, with the architecture designed from the start for GA across any vertical with a defined promotion scenario.
- Tool activation coverage: ~70% to ~100%. Automated trigger reliably activates all backend tools across target campaigns.
- SE config time: 2 hours per client to near zero. Manual 20+ tool configuration eliminated. At 300 clients and 6 campaigns per year, that frees 3,600 SE hours in the MVP cohort alone.
- Budget utilization at or above manual baseline. Automated trigger performs at parity with SE-configured campaigns — proof the system works without degrading advertiser performance.
- 100% pilot adoption. Full coverage of whitelist clients for the first pilot event before scaling to V2.
What's next
The MVP established the framework infrastructure for App and Entertainment. The long-term goal was always GA — any advertiser running a promotion scenario should be able to access Promotion Mode without SE involvement or a whitelist. The roadmap gets there through 10-15 vertical and scenario profiles with self-serve configuration, industry-specific tagging, and scaling from roughly 300 to 1,000+ advertisers.
The more important unlock is the shift from SE-driven to advertiser-driven promotion management. Advertisers who can see, control, and trust the promotion system will invest more incremental budget in it. The framework makes that possible at scale.
Reflections
The expansion beyond Entertainment was the right call. But I underestimated how much vertical-specific validation each new scenario would require before it could ship. The architectural decision to make scenarios a pluggable framework was correct — it just created a longer onboarding process for each vertical team than I initially scoped for.
The campaign-level recommendation also created friction with some vertical PMs who wanted per-ad-group flexibility. In hindsight I would have built that case earlier and more visually. The budget integrity and reporting clarity arguments are compelling but they needed to be shown, not just explained.