Promotion Framework

Overview

TL;DR

TikTok's promotion scenarios exist for one reason: to give advertisers a structured reason to increase their budget around a high-stakes moment. A theatrical release, a streaming launch, a live event. But the entire capability was locked behind a manual Solutions Engineer workflow, 20+ backend configurations per campaign, 2 hours per client, and a hard ceiling on how many advertisers could be covered during any peak window. Every advertiser outside that window wasn't just underserved, they were leaving incremental spend on the table. I saw this as both an operational problem and a market access problem: promotion capabilities were only available to whoever Solutions Engineering could physically get to, which meant a significant portion of the addressable market couldn't access a feature designed to grow their spend. I co-wrote the PRD with PM, defined the cross-vertical framework architecture, drove alignment across Solutions Engineering, vertical PMs, and Ads Core, and recommended the campaign-level approach over ad group-level. The Promotion Framework shipped for Key Account advertisers across App and Entertainment verticals, replacing the fully manual workflow with a clear path to GA across any vertical, opening promotion capabilities to the full advertiser market for the first time.

The opportunity

A platform-level capability for time-bound tentpole events

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

SE capacity, silent failures, and advertiser blindness

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

Scenario profiles, not custom engineering per vertical

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.

Stakeholder alignment

Building the case across teams with different incentives

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

Campaign level vs. ad group level

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

One scenario selection, one schedule, invisible backend complexity

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

Shipped with a path to GA

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

From SE-driven to advertiser-driven

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

What I'd do differently

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.