#Marketing Cloud99 debatiendo

It is important to disctinguish between bounce rates (hard/soft)  - which is specific to a send, and held status, which is specific to a subscriber. Are you referring to bounce rates on your latest sends? And if so - are these soft bounces? 

If you query Bounce data view, you will be able to see additional details about the bounces, and why they have occurred. If the bounce rates have spiked recently, it might be a deliverability issue - but without additional information, than what is in your original post, it is hard to tell.

Hi Sabrang, 

Marketing Cloud Engagement Data Views and Marketing Cloud Next use different data models, so the Engagement Data Views listed in the documentation aren’t necessarily available as the same views in Marketing Cloud Next. 

For Next, I’d check the corresponding Data Cloud/Data 360 DMOs and reporting capabilities for the specific data you’re trying to retrieve. Some Engagement data is available through different objects or data streams rather than through the traditional _Sent, _Open, _Click, etc. Data Views. 

If you share the specific Data Views/report fields you need, it would be easier to identify the closest Marketing Cloud Next equivalent and whether the data is available directly or needs to be surfaced through Data Cloud.

Hi Guilherme,

If the Contact Point App DMO mapping is already configured, I’d check the data ingestion and identity resolution side next. Make sure the required contact/app identifiers are populated and that the contact is correctly unified with the Contact Point App record. 

I’d also verify that the mobile app is properly configured for push notifications and that the test user/device is registered and associated with the expected contact. If the DMO is still not receiving records, checking the ingestion/mapping status and any Data Cloud processing errors should help identify where the data flow is stopping. 

If you can share the DMO mapping, the fields you’re populating for the test contact, and any errors shown during ingestion or testing, it would be easier to pinpoint the missing configuration. 

@Asim Ansari

Looking back at my question, I realize I didn't explain the problem correctly.

I can retrieve the URLs that were clicked, so there is no issue there. However, if a link hasn't been clicked, I can't retrieve its original URL.

In other words, if I want to retrieve all the links contained in a Campaign/List Email, I can't get their original URLs. The only thing I can retrieve is the tracking URL (my Marketing team doesn't use custom redirects).

On the other hand, when I retrieve click data, I can get the exact destination URL for each clicked link.

The problem is that for links that haven't been clicked, I'd have to create the records manually, because the only URL I can retrieve from the List Email is the tracking URL. This also makes it impossible to reliably match the clicked URLs with the corresponding links in the List Email.

Is there a way to retrieve the original URLs of all links in a List Email, including those that haven't been clicked?

Hi @Akhilesh Prajapati

This is Account Engagement (Pardot) territory. The infinite spinner on 

Account Engagement Settings → User Management → Users is a known symptom pattern, almost always tracing back to the Salesforce↔Pardot connector/session layer rather than an actual "Users" bug. I checked the linked community thread it has 0 replies, so no prior resolution to build on there.

Here's the diagnostic order I'd work through, most-likely-cause first:

1. Check Connector authentication statusGo to Account Engagement Settings → Connectors and check the Salesforce connector's status. If it shows an auth error (commonly surfaces as Pardot API Error 184 authentication failure), that alone is enough to hang User Management, since that page pulls live data through the connector session. Reauthenticate the connector user if it's broken.
2. Confirm the connector user still has correct accessThe user account the Salesforce Pardot connector runs as needs an active Salesforce license, System Administrator (or equivalent) profile, and the Account Engagement Administrator role in Pardot. If that user was deactivated, had their profile changed, or lost the Pardot role assignment, the connector silently fails and pages like this spin forever instead of erroring cleanly.
3. Rule out browser-side blocking (very common cause)Account Engagement Settings loads inside a Salesforce Canvas app (an iframe calling out to Pardot's API). Third party cookie blocking (Safari/Chrome privacy settings), ad blockers, or browser extensions frequently break this silently. Test in an incognito/private window with extensions disabled, and try a different browser entirely before assuming it's a config issue.
4. Check Session Settings for Clickjack Protection / IP restrictionsIn Salesforce Setup → Session Settings, aggressive Clickjack Protection settings or 'Lock sessions to the IP address from which they originated' can block the Canvas iframe from completing its callout. Also check Login IP Ranges on the connector user's profile if Pardot's servers aren't whitelisted, the callout can hang rather than fail visibly.
5. Check for multiple Business UnitsIf this org has more than one Account Engagement Business Unit, User Management can hang if the specific Business Unit context is ambiguous or misconfigured for the logged-in user. Confirm which Business Unit the affected admin is scoped to, and that their Salesforce profile maps correctly to it under Business Unit Setup.
6. Escalate to Salesforce Support with the network traceIf all of the above check out, open a case with Salesforce Support (this is a Pardot/Account Engagement product issue, not something fixable via Apex/Flow/config alone). Capture a browser dev-tools Network tab trace of the failed page load first the failing XHR call to Pardot's API will usually show the real error code even though the UI just shows a spinner.

Quickest first move: step 1 (Connectors auth status) and step 3 (incognito/different browser) these two catch the majority of real-world cases of this exact symptom. If the connector shows green/authenticated and it still hangs in a clean browser, jump to step 4 (Session Settings) before assuming it needs a Support case.

I hope you find the above information helpful. If it does, Please mark it as Best Answer to help others too.

Hi Guilherme, Custom Keys aren’t required for basic push notifications. They’re used when the app needs to receive additional key-value data in the push payload, for example to support tracking, deep linking, or custom app behavior. The mobile app code needs to be implemented to handle those keys. 

For the basic MC Next setup, you’ll need to configure the mobile app and the appropriate iOS/Android push service credentials, then configure the SDK in the app to receive push notifications. 

So if the implementation doesn’t require any custom data or app-specific behavior, Custom Keys generally aren’t necessary. If you share what the other company is asking you to configure as the Custom Keys, it may be easier to determine whether they’re actually needed. 

@Jaishree Chundawat

If you are not able to see query studio then please check if you have assigned the license to yourself from setup. 

Here are the steps - Login to SFMC > hover on your name in the top right corner > go to platform tools > Apps > Installed packages > search and click on Query Studio > click licenses > select the BU where you want to assign query studio > find your user from "find users" > check the box in front of it > click save. 

Hope this helps!