#Marketing Cloud92 diskutieren mit

Hi @Taylor Thomas

A dropped open rate isn't primarily a Marketing Cloud automation/config issue it's a deliverability problem, and the timing lines up strongly with sending pattern, not a random content issue. A few things to check, roughly in priority order: 

1. Gmail's bulk sender requirements (most likely cause) This isn't just "penalizes large lists" since Feb 2024, Gmail requires senders doing 5,000+/day to Gmail addresses to: authenticate with SPF, DKIM, and DMARC (DMARC is the one people miss), keep spam complaint rate under 0.3%, and support one-click unsubscribe (RFC 8058, List Unsubscribe header). If any of these slipped DMARC record expired, a one click unsubscribe isn't actually wired up Gmail can start routing to spam/promotions more aggressively without an outright bounce, which matches your "delivered stayed flat, opens dropped" pattern exactly (delivered ≠ inboxed). 

• Check: Email Studio → Sender Authentication Package, confirm DKIM/DMARC status isn't flagged
• Check: Deliverability dashboard / Sender Reputation in Marketing Cloud for a domain/IP reputation dip coinciding with Aug/Sep

Don't just mass-suppress unengaged subscribers as a first move do it in this order: 

1. Pull an engagement report segmented by ISP (Gmail vs. Outlook vs. Yahoo) if the drop is Gmail specific, that confirms #1 over general list fatigue
2. Check if send list composition changed recently (new list merged in, an old unengaged segment re-added) around July/August
3. Then do a sunset/re-engagement flow before an outright suppression a "we miss you" send to 90+ day unengaged, suppress non-responders, rather than deleting reputation signal all at once (a sudden big list cut can itself cause a short term reputation blip)

3. Rule out the boring stuff

• Any change to send time/day between the two affected sends vs. prior months?
• Preheader/from-name change that could affect Gmail's tabbing (Promotions vs. Primary)?
• Any new links/domains in the email that could trip spam filters?

Given the pattern (delivered flat, opens down, two consecutive sends), I'd check DMARC/authentication status first that's the one thing that silently breaks and exactly matches this symptom, more so than list fatigue alone. 

If you want, share your list size and roughly what % of your list is Gmail that'll tell us whether the bulk sender thresholds even apply to you.

@Mradul Srivastava Appreciate the link. On the substance, though — the diagnosis holds: changing a Salesforce user's password also resets that user's security token, which is exactly why the write-back (MC → SF, the journey Update Contact / Salesforce activities) broke while SF → MC kept flowing and the page still showed Connected. Re-entering the new password + fresh security token in Marketing Cloud Connect restores the write-back.

One note on the re-config steps — a credential change doesn't rename the Synchronized Data Extensions, so re-syncing objects and re-mapping every query to new DE names isn't required here; the DE names are tied to the SF objects, not the user's password. Happy to compare notes if you're seeing different behavior.

@Gabriela Levy net for you: update the connector user's new password + security token in MC Connect (or reconnect the user) and MC → SF should come back without rebuilding your DEs.

@Blake Norrish @Menno Kruijt  It entirely depends on your use case. If it is a complex one, please share the details here so that we can try to provide a better example or suggest a possible solution.

However, I’m sharing another example from @Nobuyuki Watanabe 's blog - 

https://medium.com/@marketingcloudtips/marketing-cloud-next-conducting-an-online-survey-smart-capture-form-c3fb77606565

This should certainly give you a better understanding of how, when, and why to utilize a CloudPage. 

@Ritu Srivastava It is a general practice that customers usually follow to avoid overage of contacts. If your goal is to sync only the required records from the integrated Sales Cloud then I would recommed using the report based integration practice. See steps below - 

1. Create a report of required contacts in Sales Cloud
2. Go to marketing cloud > Interactions
3. Go to Import > Create
4. Select Salesforce objects and reports from file location drop down
5. Complete the configuration and run the import definition.

You will see a new data extension (with the same name as import activity) that will be created under "Salesforce Data Extensions" folder. Follow this document for clear steps - https://help.salesforce.com/s/articleView?id=000383010&type=1

You can automate this process by using the import definition in the automation studio. 

Good question, Guru. The reason columns are missing: your script retrieves the DataExtension object, which only carries Name and CustomerKey. The COLUMNS live on a separate object, DataExtensionField, so you fetch them per DE. 

Easiest is SSJS Core (faster than WSProxy). For each customerKey you already have: 

var de = DataExtension.Init(customerKey); 

var fields = de.Fields.Retrieve(); 

var columns = []; 

for (var i = 0; i < fields.length; i++) { 

  columns.push(fields[i].Name); 

} 

Each field also carries FieldType, IsPrimaryKey, MaxLength, Ordinal, DefaultValue and StorageType, so you can capture data types and the primary key too if you want. 

So loop your existing DE list, call Fields.Retrieve per customerKey, and add that columns array into your JSON next to the Name and CustomerKey you already have. 

if this helps, please mark it as the Best Answer so it helps the next person, thanks 🙂

Hi Emily,

This mismatch usually comes down to one of two things:

1. Hidden default date filter (most likely cause) — many Data Cloud/Analytics report templates carry an implicit time-range filter (e.g., trailing 7/30 days) that isn't shown as a visible chip. Open the report in edit mode, check the lens/query for a date condition, and widen or remove it.

2. Ingestion gap — go to Data Cloud > Data Lake Objects > your Form Submission stream > Data Explorer, and check the row count there directly. If it's already ~22-24 at that level, the issue is upstream in ingestion (check the Data Stream's refresh history for a partial/failed run), not in the report.

Also worth noting: "Individual with Form Submission" counts by resolved Individual, not raw event — so if your Identity Resolution match rules are broad, some submissions may be consolidating under fewer unified profiles. That's expected for that report specifically, but it wouldn't explain a similar gap on "Form Submission Event," which should be event-level.

Start with the date filter check — that resolves this in most cases.

Hi @Aline Bin Cardoso

I think you might be missing my point. There are no standard features for doing this channel determination - so far we do agree. 

What I am questioning is the value of doing such a prioritization in first place - as channels serve very different purposes and drive very different behaviour. Also, consent is also very often channel specific (or at least it should be) so it is ultimately up to the recipient's preferences to decide, which channels they want to engage with you in.  

What one COULD consider, and what I have done successfully in the past, is to have an engagement driven "escalation path". I.e. you start with the least intrusive channel (email) and end up with the most intrusive (SMS). Meaning, that a campaign email, promoting up to 60% discount, will start as an email. It will give the recipient a broad selection of articles on sale, and provide details about the best offers. If the recipient chooses not to engage after some days (here it is up to you to decide, which criteria should define engagement), you can proceed to decide if the recipient is an app user (and send an app push) or an SMS (if you have their phone number). These two formats are quite limited, and will only be able to hold information like "FINAL CALL! Our sale ends tomorrow. Save up to 60%.

" 

If you REALLY need to have a decision split based on engagement data from across channels, you will need to build your own logic in SQL, querying across the different data views, allowing you to derive most engaging channels for a specific contact. Do keep in ind though, that while SMS will have the biggest CTR, it can also easily lead to unsubscribes due to oversaturation.

Good question, and one I'd like to answer properly, but the honest answer is that the shape of what you build changes completely depending on a few things you haven't told us yet. So let me ask rather than guess. 

First, a snag in the input list. You've got conversion rate, AOV and revenue generated as separate inputs. Those can't all be independent, either revenue is derived (contacts × CR × AOV) or it's measured from actual order data. If both, the calculator can disagree with itself on day one. Which is it meant to be? 

Is this a forecast or a scorecard? A pre-launch business case with sliders and ranges, and a post-launch "what did this actually earn us" report, are two different artefacts. Same formulas, completely different data sources and completely different build. Most of these tools get abandoned because they try to be both. 

Are your journeys always-on or campaign-shaped? For an always-on journey, ROI isn't a number, it's a curve. Contacts keep entering, conversion rate drifts, build cost is sunk and shrinking per contact over time. You'd need entry cohorts and a payback view, not a single figure. 

Do you already have holdouts running? This is the big one. Without a control group you're not measuring incremental anything, and no amount of formula design fixes that. If you do have them: are they persisted per contact, or re-rolled with Random Split on each entry? And is there a global holdout as well as per-journey ones? (Per-journey lifts don't sum to portfolio lift, and the gap matters.)

Where do revenue and cost data actually live? MCE has neither revenue nor margin nor cost of goods. That pushes the actuals half of this toward Data 360 / your warehouse / Tableau, with MCE contributing engagement and holdout membership. Is that available to you, or are you constrained to build inside MCE? 

Who owns the cost-avoidance assumptions? Cost avoidance is where business cases go to get manufactured. If Finance hasn't signed off on "cost per deflected call," it's a soft number and should be flagged as one. 

One last thing, said kindly: most of this question isn't really MCE-specific. Incrementality design, control-group methodology, margin vs revenue, cost-avoidance taxonomy: that's marketing measurement, and it would be true if you were running Braze or a spreadsheet. The genuinely MCE-shaped slice is narrow: how to persist a holdout flag so it survives re-entry, how to get engagement data out into something that can join it to orders, and whether a Cloud Page + assumptions DE is a sane place to put the front end. Happy to go deep on that slice here, since that's what this group is good at. 

For the measurement-design half you'll get better answers where the analytics and architecture folks hang out. The Marketing Architects group, or a Data 360 / Tableau group. Genuinely worth cross-posting; it's a good question, just a two-venue one. 

Tell me which of these apply and I'll happily go into the formulas with you.

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.