Data View: Subscribers

Subscribers  Data View:

Quote "This data view only returns results at the Enterprise level, and not for business units." Unquote

This is what the article states:
https://help.salesforce.com/s/articleView?id=sf.mc_as_data_view_subscribers.htm&type=5
But, I find the difference between ent._Subscribers and _Subscribers, the difference is SubscriberType. Bottom line - Always use "ent" prefix when querying this dataview.


Here is the query :

1.  select count(subscriberkey),SubscriberType from ent._Subscribers group by SubscriberType ==> ExactTarget

2.  select count(subscriberkey),SubscriberType from _Subscribers group by SubscriberType  ==> Unknown External System,, SF object or CRM.


Question :
Why they are allowing us to query _Subscribers and giving us different results in different child BUs, whereas when we query ent._Subscribers, it always gives us consistent result.

Answer :
The difference in result is because of the subscriber type. When you add subscribers to All subscribers by default, it will be "Exact Target".
Whereas for any Trigger Sends that do not use a List will use the Trigger Send Managed List. Subscribers Data View also states , the subscriber type 3. Unknow External System (Triggered Send Hidden Manage List). Here is the article : https://help.salesforce.com/s/articleView?id=sf.mc_as_data_view_subscribers.htm&type=5

This article states : https://help.salesforce.com/s/articleView?id=000352724&type=1

Salesforce V2/V3, which preceded Marketing Cloud Connect , used hidden lists to store Salesforce Subscribers. 
Marketing Cloud Connector for Microsoft Dynamics CRM also uses a Hidden Managed List.

What does this article means ?

If you imported Salesforce data into marketing cloud, it used hidden list and those records were not added to contacts till you performed the send. But, with MC Connect, Synchronized data sources from Contact, Lead, and User Records are shown in Contact Builder All Contacts.

So Why are they adding Contact, Lead and User to All contacts?

These records are added to  contacts for billing purposes.

So after the introduction of MC Connect we will find any issues ?

If you create trigger definition send and while configuring the trigger send , you escape updating the subscribers to All Subscribers, those subscribers will be managed by hidden list unknow to All Subscribers. It's recommended to update the subscribers to All Subscribers for any trigger send definitions.



Comments


Knowledge Article

Most Viewed

CLOUD PAGE ENABLEMENT - PART 1

EMAIL NOT SENT IN JOURNEY BUILDER

CONSIDERATIONS FOR JOURNEY BUILDER

Journey Builder REST API Documentation

Preference Center Demystified

Popular Posts

CLOUD PAGE ENABLEMENT - PART 1

EMAIL NOT SENT IN JOURNEY BUILDER

CONSIDERATIONS FOR JOURNEY BUILDER

Journey Builder REST API Documentation

Preference Center Demystified

SEND LOG EANBLEMENT

Share with Friends

Disclaimer:

The information provided on this technical blog is for general informational purposes only. As a SFMC (Salesforce Marketing Cloud) Technical Architect, I strive to offer accurate and up-to-date content related to SFMC and its associated technologies. However, please note that technology is constantly evolving, and the information provided may become outdated or inaccurate over time.

The content published on this blog represents my personal views and experiences as a SFMC Technical Architect and does not necessarily reflect the official views or opinions of any organization or employer I may be affiliated with.

While I make every effort to ensure the accuracy and reliability of the information presented, I cannot guarantee its completeness, suitability, or applicability to your specific circumstances. Therefore, it is essential to verify any information provided and make your own independent assessments or seek professional advice if needed.

Furthermore, any actions taken based on the information provided on this blog are at your own risk. I shall not be held liable for any damages, losses, or inconveniences arising from the use of the information presented here.

Please keep in mind that SFMC and its associated technologies are complex and require technical expertise for proper implementation and management. It is recommended to consult with qualified professionals or official SFMC documentation for comprehensive guidance.

Finally, please note that any product or company names mentioned on this blog are trademarks or registered trademarks of their respective owners. The mention of these trademarks or registered trademarks does not imply any endorsement or affiliation with the blog.

By accessing and using this blog, you agree to the terms of this disclaimer. If you do not agree with any part of this disclaimer, please refrain from using this blog.