Marketing Cloud Mobile Marketing

Marketing Cloud Mobile Marketing, Where the Constraint Is the App Team

Mobile Studio delivers push notifications, in-app messages and an inbox inside your app, orchestrated from the same journeys as email. The part nobody mentions in the demo is that all of it depends on an SDK integration and event instrumentation owned by your app developers — so a mobile program moves at the speed of their roadmap, not marketing's.

Discuss Mobile Marketing SMS & WhatsApp

12+ Years of CRM and marketing platform delivery
500+ Clients across six markets
40+ Certified Salesforce, HubSpot and AI specialists

Mobile Surfaces

Choosing a Surface

Push, In-App or Inbox? They Are Not Interchangeable

Teams default to push because it is the one everybody knows, and push is the only one that costs you permission you cannot get back. Each surface has a different reach, a different interruption cost and a different failure mode.

Mobile Studio surfaces compared
Surface	Reaches	Interruption	Use it for	Fails when
Push notification	Anyone who granted permission, whether or not the app is open.	High. It arrives on the lock screen, uninvited.	Time-sensitive things the customer would want interrupting for: a delivery, a payment failure, a booking change.	Used for merchandising. Permission is withdrawn, and it is rarely granted twice.
In-app message	Only people already in a session.	Low. They are already there.	Onboarding, feature discovery, contextual offers, asking for the push opt-in at a sensible moment.	Shown on launch to everyone, every time, until it is dismissed reflexively.
Message inbox	Anyone with the app, whenever they choose to look.	None. The customer opens it.	Content with a shelf life: offers, statements, service updates worth keeping.	Nothing tells the customer it is there, so nobody opens it and the channel is assumed not to work.
App behavioral events	Not a message — the input that makes the others relevant.	None.	Triggering journeys on real app behavior rather than on email engagement.	Instrumented after the messaging is built, so the first campaigns run blind and set expectations low.
SMS or WhatsApp	A phone number. No app required. See SMS and WhatsApp.	High, and it reaches people who never installed anything.	Reach beyond your app population, and conversational exchanges.	Treated as cheap push. It is a different channel with different consent obligations.

Capabilities verified against Salesforce documentation Last reviewed 23 September 2026

The Work

Four Workstreams, Two of Them Outside Marketing

This is the honest shape of a mobile program. The first two workstreams sit with your app team, which is why mobile initiatives stall more often on engineering capacity than on marketing design.

Workstream 01

SDK integration and instrumentation

The Marketing Cloud mobile SDK has to be integrated into the app, and the events worth acting on have to be instrumented with a taxonomy that will still make sense in two years. This is app engineering work on the app team's release cycle, and it is the constraint on everything else.

SDK integration for iOS and Android, on the app release cycle
Event taxonomy designed before instrumentation, not after
Contact identity linked between app, CRM and Marketing Cloud
Attribute collection that matches what journeys will need
Testing across app versions, including the ones customers keep
A versioning plan, because customers do not all update

Workstream 02

The push opt-in, spent carefully

Push permission is a one-shot asset on both major platforms and it is the most frequently squandered thing in mobile marketing. Asking at first launch, before the customer has any reason to trust you, is how most apps lose it permanently.

Opt-in requested at a moment when the value is already obvious
A pre-permission in-app message explaining what they will receive
Never at first launch, before any value has been demonstrated
Category-level preferences where the app supports them
Opt-in rate measured and treated as a program metric
A recovery path for the people who declined, however limited

Workstream 03

Message design and configuration

The Mobile Studio work itself: push templates, rich push, in-app layouts, inbox content, and the rules about which surface carries which kind of message. Comparatively quick — once the two workstreams above exist.

Push templates, including rich push with media and actions
In-app message design and display rules
Inbox content, with expiry so it does not accumulate
Deep links that land in the right place in the app
Localization and time-zone-aware delivery
Frequency rules applying across surfaces, not per surface

Workstream 04

Orchestration with everything else

Mobile messages belong in the same journey as the email and the SMS, not in a parallel mobile program. A customer who receives a push, an email and an in-app message about the same thing in one afternoon is experiencing your org chart.

Mobile activities inside the same journeys as email
Channel selection by context: what the moment actually warrants
Suppression shared across channels rather than per channel
Frequency capping across every channel a customer is reachable on
App behavior as a journey entry and decision criterion
Reporting that shows the customer's experience, not the channel's

Dependencies

Four Things to Agree With Your App Team Before You Start

Mobile marketing is the only Marketing Cloud channel whose delivery mechanism is owned by another department with its own roadmap, its own release cycle and its own priorities. That is the defining constraint and it is better acknowledged in week one.

Marketing teams that treat the SDK work as a ticket tend to wait a quarter. Teams that bring the app team into the design tend to get instrumentation that actually supports what they want to do.

Where the requirement can be met without the app — reaching people who never installed it — that is SMS and WhatsApp, and it has an entirely different dependency profile.

Which release the SDK work lands in

Not whether, but which release — with a date. SDK integration and event instrumentation are app engineering tasks that compete with product features for the same capacity. A mobile marketing plan with no committed release is a plan with no start date, and it is better to know that before the license conversation than after it.

The event taxonomy, designed jointly

What gets instrumented determines what can ever be acted on. Marketing knows which behaviors would be worth reacting to; engineering knows what is feasible to emit and what it costs. Designed separately, you get events that are either unusable or uneconomic. Designed together, once, they last for years.

Who owns the push permission prompt

It lives in the app, so engineering builds it — but when and how it is asked is a marketing decision with a permanent consequence. This needs an explicit owner, because in its absence the prompt defaults to first launch, which is the worst available moment.

What happens to customers on old app versions

A meaningful share of any app's users are running a version from months ago. Which surfaces work for them, what a message sent to an old version does, and whether instrumentation exists in that build are all real questions — and they arrive as a support issue rather than a design question if nobody asks first.

12+

Years delivering CRM and marketing platform transformation

500+

Clients served across global markets

250+

Platform deployments delivered

98%

Client retention rate

Failure Modes

Four Ways to Lose a Mobile Audience

Mobile has a harsher feedback loop than email. An irritated email subscriber unsubscribes from one program; an irritated app user disables notifications entirely, uninstalls, or both — and none of those are recoverable through a preference center.

All four of these are self-inflicted and all four are avoidable in design.

Asking for push permission at first launch — Before the customer has any reason to trust you with an interruption. Permission is one-shot on both major platforms, so the decline is effectively permanent — and it happened in the first five seconds of the relationship.

Push used for merchandising — A channel the customer granted for delivery updates and payment alerts, used for a weekend sale. Notifications get disabled, and the operational messages that genuinely mattered stop arriving too.

The same message on every channel — Push, email and in-app all firing for one event, because each channel was configured by someone looking only at their own. The customer does not experience three channels; they experience one brand contacting them three times.

Instrumentation after the fact — Messaging built first, events added later. The first campaigns run on installation date and little else, perform accordingly, and the program gets judged on results it was never equipped to produce.

Readiness

Five Questions Before the Mobile Program

The first three are engineering questions and the last two are design questions. If the engineering answers are uncertain, that is the sequencing problem to solve before anything else — including before the license.

Discuss Mobile Marketing

Is the Marketing Cloud mobile SDK integrated, and if not, which app release will carry it — with a date?

Which app behaviors are instrumented today, and would marketing recognize them as the ones worth reacting to?

Can the app identify a customer to Marketing Cloud, so an app action and a CRM record describe the same person?

When is push permission currently requested, and what is the opt-in rate?

Is mobile orchestrated inside the same journeys as email, or is it a parallel program with its own frequency rules?

SMS & WhatsApp

Reaching a phone number without an app, and the consent design that gates it.

Journey Builder

Where mobile messages belong: inside the same journeys as email, not beside them.

Personalization

App behavior as a real-time signal, not only as a journey trigger.

Integration

Identity between app, CRM and Marketing Cloud — the prerequisite for all of it.

Marketing Cloud Consulting

The practice page: architecture, edition selection and how an engagement runs.

Marketing Cloud Case Study

A worked example of the architecture-first approach on a real client engagement.

Common Questions

Questions About Mobile Marketing

What do we need before we can send push notifications?

The Marketing Cloud mobile SDK integrated into your app, event instrumentation for the behaviors you want to act on, and a push permission prompt that has actually been granted. All three sit with your app development team and land on their release cycle.

That is the real constraint on mobile marketing and it is worth establishing before a license conversation rather than after. Mobile Studio configuration is comparatively quick; the SDK work is what sets the date.

When should we ask for push permission?

After the customer has experienced something valuable, and at a moment where the reason for the interruption is self-evident — after a first order when they would want delivery updates, not on first launch before they know what the app does.

Permission is one-shot on both major platforms, so a decline is effectively permanent. The pattern that works is a pre-permission in-app message explaining what they will receive, shown at a relevant moment, with the system prompt only for people who say yes to that. It costs a little reach and protects the asset.

What is the difference between push and in-app messages?

Push reaches the device whether or not the app is open, and requires permission. In-app messages are shown to someone already in a session, require no permission, and cost nothing in goodwill because the customer is already there.

They suit different jobs. Push is for things worth interrupting someone for. In-app is for onboarding, feature discovery, contextual offers — and for asking for the push opt-in at a moment when it makes sense.

Should mobile be a separate program from email?

No. Mobile activities belong inside the same journeys as email, with shared suppression and frequency capping across every channel a customer is reachable on.

Run separately, the predictable result is a customer receiving a push, an email and an in-app message about the same thing in one afternoon — each channel behaving correctly by its own rules. The customer does not experience channels; they experience a brand that is not paying attention.

Can we message people who do not have our app?

Not through Mobile Studio's in-app surfaces, which by definition require the app. To reach a phone number without an app you need SMS or WhatsApp, which is a different channel with different economics and a different consent obligation.

That is frequently the right answer when app penetration is low, and it removes the app-team dependency entirely — which is why it is often the faster route to a mobile presence.

How do we measure whether mobile is working?

Not on push open rates, which are noisy and flatter the channel. The metrics that matter are opt-in rate and its trend, notification disable rate, the downstream action a message was supposed to cause, and retention among messaged versus unmessaged cohorts.

The disable rate is the one to watch most closely. It is the mobile equivalent of a complaint, it is not recoverable through a preference center, and it is usually the earliest signal that the channel is being overused. More on measurement on the reporting page.

Next Step

Start With the App Team, Not With the Campaign

Tell us whether the SDK is integrated and what is instrumented today. Those two answers determine whether this is a configuration engagement or an engineering sequencing conversation.

Discuss Mobile Marketing SMS & WhatsApp

Relatable? We should definitely talk.

What we'll cover:

From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.

Identify revenue leaks across CRM, integrations, and GTM
Design and optimize complex systems (CRM to Custom Apps)
Apply practical AI to improve operations and pipeline conversion
Eliminate silos and build a unified revenue system
Assess GTM performance and key bottlenecks
Align teams with clear processes and ownership
Define a scalable RevOps model
Improve forecasting and reporting
Review your HubSpot/Salesforce setup for scale