Hi all,
What is the best way to add a real-time countdown timer to In-App Messaging in Salesforce Marketing Cloud (MobilePush)
for flash sales/limited-time offers?
#Marketing Cloud #Mobile #In-App Guidance #Campaigns
Hi Erkan - short version: MobilePush in-app message templates don't have a native countdown-timer widget, so a real-time ticking timer comes down to either custom HTML/JS or letting the app render it. The options, best-to-quickest:
1. Custom HTML in-app message with JavaScript (best for a true real-time timer). MobilePush lets you use custom in-app content, so you can drop in a small countdown that runs client-side - a setInterval that ticks down to your offer's end timestamp and updates the display every second. That gives you an actual live, second-by-second timer inside the message. Pass the end time in (or set it per campaign) and the JS counts down to it.
2. App-side native rendering (most robust). Because in-app messages are drawn by the MobilePush SDK inside your app, the most reliable approach is to send the offer's end timestamp as a custom key/payload on the message and have your app's own code render a native countdown UI. Sturdiest for a real-time timer, but it needs your mobile dev team.
3. Dynamic countdown GIF as the message image (quickest, lowest-dev). Services like NiftyImages or Sendtric generate an animated countdown GIF from a target date, and you use that as the in-app image. Fast, no code - but two caveats for in-app: animated-GIF rendering isn't guaranteed across every in-app SDK/OS, and images can be cached or pre-fetched, so it's more of a 'looks like it's counting' animation than a guaranteed-accurate live clock. Great for email, a bit less dependable in-app.
For flash sales, I'd go with option 1 (custom HTML + JS) if you want a genuine real-time countdown a marketer can manage, or option 2 if you want it rock-solid and have app-dev support. Option 3 is the fast path if a close-enough animated countdown is acceptable.
One tip whichever you pick: drive the timer off the offer's actual end timestamp (not a duration from open), so it stays accurate no matter when the user sees the message.
Hope that helps!