What is a zero-release campaign?
Used in a sentence: The festive banner has to change every evening this week, so let's run it as a zero-release campaign instead of waiting for the next build.
How it works
Normally, any visible change to a mobile app means writing code, building a new version, passing store review and waiting for users to update. A zero-release campaign skips that cycle.
The app includes an SDK that knows how to render a set of components, such as banners, sheets, cards and videos. The content and rules live on a server. When a team publishes a campaign, the SDK fetches the new configuration and shows it the next time its trigger fires. Edits, pauses and rollbacks work the same way, so a mistake can be fixed in minutes rather than in the next release.
Example
A fantasy sports app wants a live banner on the home screen that changes with each match. Shipping that through app releases would mean the content is always behind. The growth team builds the banner as a zero-release campaign, updates the teams and timing from the dashboard before each match, and pauses it once the tournament ends, all without touching the app code.
Zero-release campaign vs feature flag
| Zero-release campaign | Feature flag | |
|---|---|---|
| What changes | New content and layout | Code already in the build |
| Who uses it | Growth and product teams | Mostly engineering |
| Needs a release first | No, beyond the SDK | Yes, the code must ship |
A feature flag switches on something already built. A zero-release campaign delivers something new.
Best practices
- Agree which components growth can change freely and which need engineering review.
- Use templates so new campaigns stay consistent with the app’s design.
- Preview on real devices before publishing.
- Keep a rollback ready and target a small audience first.
How to do this with Digia Engage
With Digia Engage, engineering integrates the SDK once and growth teams then design, target and publish campaigns from a no-code builder. Most teams have their first campaign live within 24 hours. Probo uses this approach to ship feature rollouts and in-app experiments without app store dependencies; see the Probo case study.
Frequently asked questions
- What can you change in an app without an update?
- Anything the app renders from server-side configuration: in-app messages, banners, bottom sheets, widgets, surveys, offers, copy, images and, with server-driven UI, whole screen layouts. What you cannot change is native code the app does not already contain, such as a new device permission or a new payment integration.
- How do growth teams ship campaigns without engineering?
- Engineering integrates an engagement SDK once. After that, growth teams design campaigns in a visual builder, choose triggers and audiences from existing analytics events, and publish from a dashboard. Engineers stay involved for new events or native features, but routine campaign work no longer waits for a sprint or release.
Related terms
Read more
Part of the In-app engagement glossary.