How your DiscoBeat launch works

Launching DiscoBeat takes five phases, from kickoff to your first publishers going live. This article explains what happens in each one, what your team does, and what Disco does. Your Disco contact will share a launch plan showing where your specific launch stands.

Before you start

You will need a technical contact who can implement on your surfaces, and a decision on which surfaces you want to monetize first. Everything else is provisioned by Disco during kickoff.

Disco serves offers to shoppers in the United States today. You can enroll publishers with international traffic, but offers currently serve on US traffic.

The two workstreams of a DiscoBeat integration

Every launch runs two workstreams in parallel. The phases below cover both.

Publisher management is the ongoing operation: creating publishers, setting category exclusions, and controlling who is enabled. It starts at Channel setup (Phase 2) and never stops — it is how you keep adding publishers for as long as you run DiscoBeat. There are two ways to do it, and you can use both.

• Channel Management. The interface Disco provisions for you at kickoff. Nothing to build, available from day one.
• The Channel API. For managing publishers from inside your own product, so a publisher can enable ads without leaving your interface. This is a build on your side — and it is not a serving integration. Talk it through with your Disco contact before you commit to it, so we can look at what it means for your team long term.

Serving offers is what your engineers build: how an offer reaches a page and gets rendered, using one of the methods in the next section. It is built once per surface, in Build & verify and Surface checks (Phases 3 and 4).

You can start onboarding publishers before your serving integration is complete — but no offers appear until both pieces are ready. A publisher you enable in Phase 2 shows nothing until your serving integration is built and verified.

How you integrate, by surface

Your surfaces determine your methods, and most partners use more than one. You do not have to build them at once. Adding a surface later is normal, and each new surface runs through the same phases described below.

The Web SDK is the default for anything on the web. Disco renders the offer for you, which means formats, fixes, and improvements ship without work from your team. If you are considering the Ad Recommendations API for a web surface, raise it with your Disco contact first so we can look at the trade-offs together.

For every partner, whichever methods you use

• Channel Management covers the ongoing operation with nothing to build: manage publishers and exclusions, and read your reporting.
• The Channel API is an optional build, for managing publishers and exclusions from inside your own product.
• The Reporting API is an optional pull, for feeding channel and per-publisher performance into your own reporting stack.

Phase 1: Kickoff & access

Disco provisions your channel and your Channel Management login, and confirms your reporting expectations and category exclusions with you.

Your part is to nominate your contacts (an executive sponsor, a technical lead, and a day-to-day owner) and confirm the surfaces in scope.

Phase 2: Channel setup

Your channel gets its keys, your publishers, and its guardrails.

You create your staging and production API keys yourself, under Developers, then API keys. One nuance worth knowing from day one: these are management keys, used to call the Channel API and Reporting API. They are never used for ad serving. Each publisher serves with its own ad-serving key, created automatically when Disco approves the publisher.

You add your publishers, either in Channel Management or through the Channel API, and set any category exclusions you want applied. Exclusions can be set once for your whole channel or per publisher. Disco reviews and approves them: most requests are approved automatically, usually within minutes of submission. Requests flagged for a closer look are approved within 1 business day, and bulk submissions can take 1 to 2 business days depending on size. Complete and accurate publisher information (exact business name, correct URLs) speeds approval; for bulk submissions, one bad entry can slow the batch.

Adding publishers is not a step you finish: it continues for as long as you run DiscoBeat, using the same tools. See Managing your publishers. And remember the two layers: a publisher enabled now shows nothing until your serving integration is live.

Disco also enables your agreed reporting metrics in this phase.

Phase 3: Build & verify

Your team implements each method on the surfaces it covers, following the guide linked above, staging first. Disco supports your team throughout, through your shared channel or your Disco contact.

One thing worth knowing early: the more shopper and order context you pass with each request, the more relevant the offers Disco can return. Relevance is what drives your revenue, so completeness here pays off directly. Each integration guide lists what is required and what is recommended.

Verification is joint. Your team fires test requests from your side, and Disco confirms they arrive complete, that offers render correctly, and that a test conversion tracks end to end. You can run test requests without affecting reporting or attribution by marking them as sandbox requests. We verify in staging first, then in production before anything is live to shoppers.

Phase 4: Surface checks

Every page type in scope gets verified separately before anything goes live: you repeat the verification on each surface confirmed at kickoff, and Disco confirms each one from our side, so nothing launches unverified.

If you are integrating more than one method, each is verified separately. A verified web integration does not verify your app.

Phase 5: Go-live & baseline

Your first publishers go live. Disco manages rendering and optimization through an initial baseline period, so your launch starts from verified performance rather than guesswork. After the baseline, we review the results with you and agree how to scale up, including whether you want to take over rendering.

What a good integration looks like

• Placement earns its position. Offers placed higher on the page get seen more, and viewability drives revenue directly. Place the unit above the fold where the surface allows; moving a unit lower on the page measurably reduces yield.
• Context is complete. Pass the recommended attributes, not just the required ones. Relevance drives revenue, and relevance comes from the context you send (see Phase 2).
• Each surface reports cleanly. Give every surface its correct page type so performance splits by surface in your reporting from day one. This matters more the more surfaces you run.
• Nothing ships untested. Sandbox requests are verified before production (see Phase 3), so launch day is confirmation, not discovery.

After you launch

You can read channel and per-publisher performance in Channel Management (see Channel performance reporting), or pull it programmatically with the Reporting API. Your Disco contact can enable the specific metrics your team wants to report on.

Related

• Web SDK guide, the web serving integration
• Ad Recommendations API, for serving offers in your own UI
• Channel API, for managing publishers and exclusions
• Reporting API, for channel and publisher performance
• Channel Management, the dashboard tab by tab
• Channel performance reporting
• What is DiscoBeat?