#Marketing Cloud92 utenti parlano di questo argomento

Hi @Yashasvi Gaur

- You have two ways 

1.  Directly from Email Studio  -  Go to Email Studio -> Open Tracking  ->  Select the email send   ->  Go to Conversions   ->  Click the number under Unique Conversions  ->  This displays the subscribers associated with those conversions  

2.  If you need to retrieve the subscriber information into a Data Extension, use the Marketing Cloud tracking Data Views. For example, _Sent, _Click, and _Job can be joined to identify who received the email and who clicked it. Salesforce specifically recommends SQL/Data Views when subscriber-level tracking data needs to be customized or automated. 

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!

This is a really common modeling problem, and you are already on the right track with campaigns. The key realization: product interest is a time-stamped many-to-many (one person to many products, each with a date/source), so it should not live as fields on the Lead, a multi-select picklist loses the timeline and does not survive conversion. Two layers that work well together: 

1. Keep using Campaign Members for the 'raised their hand' events, it is the right call. Add a custom Product field (lookup to Product2, or a picklist) on the Campaign so each campaign is tied to a product, then a person's interest history is simply their Campaign Members: 'Product A campaign, January' plus 'Product B campaign, July.' Campaign Members work for both Leads and Contacts and survive Lead conversion, so the history is not lost when a lead converts. You can report interest-by-product by grouping Campaign Members on the Campaign's Product field. 

2. For a cleaner, queryable model, add a custom 'Product Interest' junction object: lookups to Product2 and the person, plus Date, Source/Channel, and a Campaign lookup. That gives you one time-stamped row per interest signal, trivially reportable as 'everyone interested in Product B since June,' and it drives scoring/routing far better than picklists. 

On the Lead-vs-Contact identity snag (the person could be either): the pragmatic pattern is to capture pre-conversion interest via Campaign Members, and once they convert/de-dup to a single Contact, hang the Product Interest records off that Contact. If you have Data Cloud, its Unified Individual solves the same-person-across-Lead-and-Contact problem natively. 

Since this is tagged Marketing Cloud: if you are on Account Engagement (Pardot), Scoring Categories are purpose-built for this, a separate interest score per product line, so one prospect can score high on Product A and low on Product B independently. Pair that with the campaigns above and you get both the engagement history and a per-product interest score. 

Net: campaigns (with a Product field) for the event history + a Product Interest junction object for the clean many-to-many, converge everyone to a single Contact, and use Pardot Scoring Categories per product if you have AE. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)

Hi Himanshu,  

Thanks for the help — the fix worked. Reply-To now shows correctly through the custom RMM settings on the Sender Profile. 

Thanks again for the quick support. 

Best regards, Juan Carlos

Hi @Santosh Gund

I opened a case and received the following response. I think the only option is to wait until the matter is resolved. 

Please be informed that the team is working internally to add more capacity to spin up the orgs related to orgfarm orgs related to the Trailhead. 

Yes, you can automate part of the Sandbox → UAT → Production promotion, but I wouldn’t treat Marketing Cloud Next as a “deploy the entire org with one metadata package” scenario yet. 

My approach would be: 

1. Use Salesforce CLI / VS Code + source control for components that are exposed through Salesforce Metadata APIs and are supported for deployment.
2. Keep all deployable metadata in Git and promote the same version through Sandbox → UAT → Production rather than rebuilding it separately in each environment.
3. For Marketing Cloud Next-specific assets/configurations, first verify whether that particular component is exposed as deployable metadata. Some configuration, connections, credentials, environment-specific settings, and certain marketing assets may still require manual configuration or a separate API/process.
4. Maintain an environment configuration checklist for anything that cannot be source-controlled, especially authentication, endpoints, integrations, permissions, and environment-specific IDs.
5. After deployment, run validation/smoke testing in UAT before promoting the same release to Production.

For a real project, I’d structure the pipeline roughly as: 

The important part is to inventory the Marketing Cloud Next components first and classify each one as

. That prevents surprises when trying to promote the complete setup. 

I’d also be interested to hear if anyone has implemented a fully automated CI/CD pipeline specifically for

, particularly which newer MC Next assets they’ve successfully managed through Salesforce CLI/Metadata API.