#Marketing Cloud102 utenti parlano di questo argomento

Exclusion at send time and filtering at build time solve different problems, and you want the second one.  

A filtered data extension re-evaluates its filter on its own, so if unengaged can be expressed as a filter on fields that live in the source DE, add it there and you are done. The catch is that open data lives in the tracking data views, not in your sendable DE, so a filter cannot see it.  

That is why this usually becomes a SQL Query Activity in Automation Studio writing to a sendable DE, joining your audience against _Open for the last 90 days and keeping the non-matches. Put the query ahead of the send in the same automation so the list is never stale.  

Decide one thing before building it: whether unengaged means no opens, or no opens and no clicks. Open tracking has been unreliable since Apple Mail Privacy Protection, and a suppression list built on opens alone will cut people who are reading. 

A 365-day clock in Marketing Cloud almost always means a data retention policy, and retention is configured on the data extension and counts from creation.  

Open the DE properties and look at Data Retention Policy. If it is set to a period after creation rather than a rolling window on individual records, everything in it cleared on the anniversary. A Data Extension entry source with nothing in it admits nobody and logs no error, which matches what you are seeing.  

The other candidate is whatever populates the DE. If an Automation Studio schedule fills it, check that schedule's end date and last run time. Recurring schedules take an end date and a year out is a common default nobody revisits.  

Those 6,000 records are in Salesforce, not necessarily in the DE. Check the DE row count before assuming the journey is at fault. 

@Taylor Thomas

Good that rules out the most common silent failure cause, so this now points toward reputation/engagement rather than authentication. With 65k/123k on Gmail, you're well past the bulk sender threshold, so their spam-rate and engagement bar applies fully to you. 

1. Gmail Postmaster Tools - do this first, it's the actual source of truth Everything above is inference from opens; Postmaster gives you Gmail's own view: 

• Spam rate - this is the one that matters most. Gmail wants this under 0.10%, and anything approaching 0.3% risks bulk filtering. Marketing Cloud's own complaint tracking undercounts this people who just hit "report spam" without unsubscribing don't always show up the same way in MC's complaint metrics.
• Domain/IP reputation High/Medium/Low/Bad bucket, tracked daily
• Delivery errors and feedback loop data
• Needs domain verification (TXT record) if not already set up, this alone is worth doing regardless of the current issue, since you'll want the historical trend once you have it.

2. Segment your engagement report by ISP before doing anything else

If open rate dropped roughly evenly across Gmail/Yahoo/Outlook, that points more toward content/list fatigue than a Gmail specific inbox placement issue. If it's disproportionately Gmail, that confirms reputation/spam rate as the driver. This one check tells you which of the two paths below to prioritize. 

Since authentication passes, a spam rate creep is the next most likely explanation for exactly this symptom (delivered flat, opens down). Things that quietly push spam rate up: 

• A list merge/import around July/Aug that added lower-quality or older contacts
• No visible/working one-click unsubscribe (Gmail requires the List Unsubscribe header AND that it actually works within 2 days) if someone can't easily unsubscribe, they hit "report spam" instead
• Content changes (new sender name, new link domains, more images) that shifted spam filter scoring independent of reputation

4. Sunset flow before mass suppression

Once you know the spam rate and whether it's Gmail specific, then move to hygiene but sequence it: 

• Re-engagement send to 90+ day unengaged (low risk subject line ask if they still want these)
• Suppress non responders after that, rather than a single large deletion a sudden big cut can itself cause a short-term reputation dip right when you're trying to recover

Hi Taylor, 

Two different signals here: Spam Rate (0.03–0.08%) = user complaints on delivered mail — that's fine. "Suspected spam" delivery errors (71.53%!) = Gmail rejecting/deferring mail at SMTP before it's even delivered. That's your open-rate drop right there — rejected mail can't be opened. 

Since template/process are unchanged, likely causes: 

1. List engagement decay — reusing the same DE monthly means unengaged/dead Gmail addresses pile up over time. Gmail's filtering is engagement-based, so this alone can trigger a spike even with zero content change. Prune addresses with no opens/clicks in the last 3–6 sends. 

2. Auth drift — SPF/DKIM/DMARC can silently break (DNS changes, key rotation, lookup limits) without touching the email. Check a recent header via Google's Messageheader tool. 

3. Check Postmaster's own Domain/IP reputation graphs (not SenderScore — different data source) for a Gmail-specific drop to Medium/Low. 

4. Tracked/redirect links in the template can carry their own reputation issues independent of content — test them via Google Safe Browsing/VirusTotal. 

Start with #1, it's the most common cause of this exact pattern. 

Reference:

Hi Michael,

The issue is that /img/samples/stars_100.gif, stars_200.gif, and stars_300.gif are Salesforce's sample images, and those images are based on the standard 5-star rating scale. Changing the picklist values doesn't change the number of stars in the image itself. 

If you want a true 3-star display, you'll need to use your own 3-star image files as a Static Resource and reference those in the formula.

For example:

IMAGE(
    CASE(
        Grade__c,
        "1", "/resource/YourStarResource/star_1.png",
        "2", "/resource/YourStarResource/star_2.png",
        "3", "/resource/YourStarResource/star_3.png",
        "/resource/YourStarResource/star_0.png"
    ),
    "Rating"
)

Create the appropriate 0-, 1-, 2-, and 3-star images and upload them as a Static Resource. That way the displayed scale is actually limited to 3 stars. 

@Brad Gallagher

A few things stand out. At ~1,000 sends/month, a shared IP is actually the right call — a dedicated IP needs steady high volume (think 100k+/month) to stay warm, so moving to one would likely hurt deliverability, not help. The trade-off of a shared IP is that your reputation is partly tied to the other senders in that pool, so a sudden jump in blocked bounces can come from them even when your own auth and content are clean (which your Email on Acid scores back up). 

Because your volume is low, reputation is domain-driven more than IP-driven — so check Google Postmaster Tools (domain reputation + spam rate) and pull your bounce logs to see exactly which receiving domains are blocking and the reason they give; a blocked bounce almost always names a blocklist or policy. Worth checking the shared IP against Spamhaus too. 

On switching to the other BU's domain — I'd hold off. That mostly moves the problem (and risks dragging their domain down); better to pin down the actual block source first. 

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

Is the campaign set to run on a recurring schedule? 

Whether newly added members enter the flow depends on the campaign schedule. If it is a one-time send and that scheduled run has already occurred, adding members to the Actionable List afterward will not cause them to enter the flow. 

If it is running on a recurring schedule, newly added members can enter at the next scheduled run. 

They will not join the flow at the point where existing members currently are. There is no functionality for members to enter partway through the flow—they always enter from the beginning when the flow runs.