Porting a Unity Prototype to a Publisher SDK in One Afternoon

A publisher SDK needs four things from your build: their package at the version they specify, their event names fired exactly as documented, ad placements wired to their mediation, and a verified test build showing data arriving. Prototypes built with these in mind integrate in an afternoon.

Why this matters

Integration is the last step before a test, which means every hour spent on it delays the answer you are waiting for.

It is also the step where a prototype most often fails silently. The build runs, the game plays, and no data arrives. Discovering that after a test has run wastes the test budget as well as the time.

Most of the difficulty is avoidable by knowing what is coming.

What the SDK actually needs from your build

Four requirements, and they are consistent across publishers even though the details differ.

1. A supported engine version. Publisher packages usually target a range. Being outside it is the most common source of a day lost to compile errors.
2. A clean initialisation point. The SDK needs to start early, once, before anything reports to it.
3. Their event names, exactly. Renamed or restructured events break their dashboards silently.
4. Control over ad placements, so their mediation decides when an ad shows rather than your code.

The last one surprises teams that built their own ad logic. Publishers generally want to control frequency and placement centrally, and a prototype with hard-coded ad timing usually needs that removed.

A publisher SDK is not a library you call. It is a contract about what your game reports and who decides when ads appear.

Events you must fire

The exact list varies, but the shape is stable.

Two rules save most of the pain.

Fire level events on every attempt, including retries. Publishers calculate difficulty and drop-off from these, and skipping retries makes a game look easier than it is.

Send the identifier as a consistent type. Mixing a level number and a level name across events is a common cause of a dashboard that shows nothing useful.

Mediation and ad placement setup

Mediation decides which ad network fills each request, and the publisher usually configures it on their side.

Your side of the work is small but specific.

• Define named placements rather than calling a generic show function. Interstitial after level, rewarded for a hint, and rewarded for a continue are different placements and are reported separately.
• Ask before showing. Check that an ad is available, and handle the case where it is not without blocking the player.
• Handle the callbacks. Ad closed, ad failed, and reward earned all need paths. The reward path in particular must be robust, since granting a reward twice or never are both live issues.
• Never block the first session on an ad request. A new player waiting on a network call is the worst possible first impression.

Frequency belongs to the publisher, not to you. Remove your own timers and let their configuration drive it.

Common integration errors

Six that account for most lost afternoons.

1. Events that fire in the editor and not in a release build. Usually caused by code stripping removing something reached only through reflection. This is the single most common failure.
2. Initialising too late, so early events are dropped silently.
3. Duplicate initialisation from a scene reload, producing double counting.
4. Mismatched package versions between the SDK and its dependencies.
5. Missing platform configuration, such as an application identifier not set in the correct place.
6. Events fired before consent where the region requires it, which can invalidate the data.

The first one deserves care. Test on a release build, not a development build, and check the dashboard rather than the console. Everything else on this list produces visible errors; that one does not.

The stripping settings involved are covered in Cut Your Unity Build Size in Half.

Verifying the integration before you submit

Do not submit until all five of these pass.

1. Install a release build on a real device, cold.
2. Play one full session: launch, start a level, fail one, complete one, and background the app.
3. Open the publisher dashboard and confirm every event appears, with the right identifiers.
4. Trigger each ad placement and confirm it reports.
5. Reinstall and repeat, confirming a fresh install is counted as new.

Write the result down. A short note saying which events were verified, on which device, on which build, saves an argument later when a number looks wrong.

The wider pre-submission list is in The Publisher Submission Checklist.

What we would do

Build prototypes with a thin analytics wrapper from day one: a single call site for each event, with the publisher's names filled in later. It turns integration from a search through the codebase into changing one file.

Keep ad logic out of gameplay code entirely. A prototype that asks a placement manager for permission is ready for any publisher's mediation; one with a timer in a level script is not.

Then verify on a release build every time, even when the integration has not changed. Stripping settings and package updates both break this quietly, and the check takes ten minutes.

The short version

• The SDK needs a supported engine version, early initialisation, exact event names, and control of ad placement.
• Fire level events on every attempt, including retries, with consistent identifiers.
• Use named placements and handle every ad callback, especially the reward path.
• The most common failure is events working in the editor and not in a release build.
• Verify on a release build against the dashboard, not the console.
• A thin analytics wrapper written on day one turns integration into an afternoon.

Add a single-call-site analytics wrapper to your prototype template this week. If you would rather hand the integration to someone who has done it before, get in touch.

Related reading: SDK Costs Inside Your Game, The Publisher Submission Checklist, and From Prototype to Soft Launch.