Promotion Framework

Overview

TL;DR

TikTok's promotion scenarios let advertisers tell the platform that a campaign is tied to a high-stakes moment, like a theatrical release, a game launch, or a live event, so the system can optimize for it. But the capability was locked behind a manual Solutions Engineering (SE) workflow: 20+ backend configurations and about 2 hours of SE time per client, which capped how many advertisers could be covered during any peak window. Every advertiser outside that capacity missed out on a feature built to grow their spend. I treated it as both an operational problem and a market access problem. I co-wrote the PRD with PM, defined a framework that lets any vertical add a promotion scenario without new engineering, aligned Solutions Engineering, vertical PMs, and Ads Core around a measurable reliability bar, and drove the recommendation to place promotions at the campaign level. The framework shipped for Key Account (KA) advertisers in App and Entertainment, raised tool activation coverage from about 70% to 100%, cut SE setup time to near zero, and was built from the start for general availability across any vertical.

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 launches. It worked, but it depended entirely on Solutions Engineers. Advertisers had no visibility into it, nothing switched off automatically when the window ended, and each client took about 2 hours of setup, which capped how many clients could be covered during any peak event.

I noticed the underlying need wasn't unique to Entertainment. Any vertical running a time-bound tentpole event, whether a game launch, a World Cup betting window, or a flash sale, needed a way to tell the platform that this campaign is different and should be treated accordingly. TikTok Ads Manager had no productized way to do that. I saw a platform-level capability any advertiser could eventually use, brought it 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.

• SE capacity was the ceiling. Configuring 20+ backend tools at about 2 hours per client meant coverage during high-volume events was limited by headcount. Uncovered clients underperformed, which meant direct revenue loss.
• Failures were silent and irreversible. Tool status was checked per client and per tool, with no global view. A tool that failed to activate on launch day had no recovery path.
• Advertisers were in the dark. They couldn't see promotion status, which tools were active, or how their campaign was being optimized. With no automatic exit when the window closed, leftover settings caused cost-per-acquisition spikes after the promotion ended.

Underneath all of this was a scaling problem. Vertical playbooks lived in scattered docs with no shared structure, so every new vertical had to be onboarded by hand, with nothing reused.

Defining the framework

Scenario profiles, not custom engineering per vertical

The core work was defining how a promotion system could scale across verticals without 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, and the backend optimizations are never shown to the advertiser. That separation let the system scale horizontally. A new vertical adds a scenario profile rather than a new product.

In the flow, allowlisted clients turn on Major event promotion at the campaign level, choose a scenario, and set a promotion schedule. The backend then applies the right optimization bundle for the promotion type, aggressive or moderate, with no SE involvement.

The table below shows how that maps in practice.

Stakeholder alignment

Building the case across teams with different incentives

Getting this built meant aligning teams with different incentives. Solutions Engineering needed to trust that automated tooling would match the quality of their manual configuration. Vertical PMs needed an onboarding path that didn't require a full engineering engagement for every 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, and the framing that got traction was opportunity sizing. The MVP cohort was 300 advertisers running 6 campaigns a year each, at 2 hours of SE time per client: 3,600 SE hours in the MVP alone. At 10 verticals with 50 clients each, that grows to 4,000 to 8,000 hours a year. That made the case about revenue: SE capacity was the constraint on growth during peak events.

Getting Solutions Engineering on board required demonstrating reliability. We aligned on one success metric, tool activation coverage from about 70% to about 100%, which gave SEs 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 campaign budget optimization (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, one schedule, and complexity the advertiser never has to see

For advertisers, the whole experience came down to a single toggle and an event type: a Major event promotion option shown after objective selection, available to clients on the allowlist. That simplicity was the point. The design principle was that backend complexity should stay invisible, and the system should communicate expected benefits instead of tooling. An advertiser running a game launch doesn't need to know which delivery reserves are switching on. They need to know that this scenario will maximize cost-per-conversion efficiency during their launch window.

Keeping the toggle optional also mattered. It meant the feature never stood in the way of new advertisers setting up a standard campaign.

Most of the design work happened a layer down, in the framework: what each scenario promised, which defaults it set, and how vertical teams wrote the benefit language advertisers would read. Getting that layer right is what let the interface stay this small.

For the MVP, the automated trigger's ~100% activation rate addressed silent failures at the source, and the promotion schedule scoped every optimization to the event window. Giving advertisers visibility into promotion status is the next step on the path to GA.

Outcomes

Shipped with a path to GA

The Promotion Framework shipped to an allowlist of Key Account advertisers as the MVP, with an architecture designed from the start for general availability (GA) across any vertical with a defined promotion scenario.

• Tool activation coverage from ~70% to ~100%. The automated trigger reliably activates every backend tool across target campaigns, closing the silent-failure gap.
• SE setup time from about 2 hours per client to near zero. Manual configuration of 20+ tools eliminated, freeing 3,600 SE hours a year in the MVP cohort alone.
• Budget utilization at or above the manual baseline. Automated trigger performs at parity with SE-configured campaigns — proof the system works without degrading advertiser performance.
• 100% pilot adoption. Every allowlisted client used the framework 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 turn on Major event promotion without SE involvement or an allowlist. 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.

The pattern I'd carry forward is how trust got handed over. Solutions Engineers gave up manual configuration once the system met a reliability bar they had helped define, and not a moment before. Whenever automation takes over work people used to do by hand, agreeing on that bar has to come before the handover.