#Email Marketing4 discussing

Subscriber Key Mapping: When creating a Sendable Data Extension, you must define which field relates to the Subscribers > Subscriber Key. If you accidentally map a field that doesn't exist in All Subscribers, or if you fail to set this relationship at all, the "send" will find 0 valid targets and effectively fail to deploy.

Correct answer is C - '

We used to have a similar setup (picklist lead source field in Salesforce, populated by our marketing automation tool) and found it was pretty much useless when it came to actually running reports and understanding where our leads were coming from.

The problem with a single "Lead Source" picklist is that it tries to do too many things at once. Is "Inbound - LinkedIn" referring to someone who came from a LinkedIn ad? An organic LinkedIn post? And what about the context of how they converted, or what page they landed on? 

We ended up switching to a three-field setup that gave us way more insight: 

The first set of fields we called "Lead Source" and "Lead Source Detail", and they captured information about how the person became a lead. So if someone filled out a Get a Quote form, it would be something like Lead Source = Web, Lead Source Detail = Get a Quote. If they downloaded an eBook, it would be Lead Source = Content, Lead Source Detail = Name of the eBook. We populated these using Pardot completion actions or automation rules based on which form was submitted. 

The second set of fields were what we called the Channel fields (Channel, Channel Drilldown 1, Channel Drilldown 2, Channel Drilldown 3). These captured where the person came from, so they'd be populated with values like Organic Search, Paid Search, Paid Social, etc. along with further detail like the campaign name, ad group, keyword, etc. These were populated by a tool called Attributer. It tracked where people came from when they first landed on the site, stored it in a cookie, and then passed it through with each form submission. 

The third set of fields were Landing Page and Landing Page Group. These tracked the first page the visitor landed on. So it might be something like Landing Page = yoursite.com/blog/example-post

and Landing Page Group = /blog. These were also populated by Attributer and helped us understand what content on our site was actually generating leads. 

With these three sets of fields together, we could look at a lead and see the full picture. Like, this person came from our Google Ads, landed on our pricing page, and requested a quote. Or this person came from Organic Search, landed on a blog post, and downloaded an eBook. Those two leads are very different, and it was really useful to be able to separate out the high-intent leads from the content leads that were probably never going to convert into customers.

Hope this helps

Aaron

Hi Pratik, 

The cleanest way to integrate Zoom Webinars with Marketing Cloud is via API + Automation Studio (or a middleware like MuleSoft/Zapier if you prefer low code). 

Recommended step-by-step approach: 

1. Create a Zoom JWT / Server-to-Server OAuth app in Zoom Marketplace. 
2. Use Zoom APIs to pull: 
3. /webinars/{id}/registrants 
4. /webinars/{id}/participants 
5. Webinar details endpoint 
6. In Marketing Cloud, create: 
7. Data Extensions for Registrants, Attendees, Webinar Info 
8. Use: 
9. SSJS Script Activity in Automation Studio (REST calls to Zoom API), or 
10. An external middleware (Azure Function / MuleSoft) to fetch + push data into MC via REST API. 
11. Schedule automation to run post-webinar or daily sync. 
12. Use SQL queries to segment (Registered vs Attended vs No-Show). 

If near real-time updates are needed, configure Zoom Webhooks and push data into MC via API. 

For enterprise setups → Middleware is cleaner.  

For quick setup → Automation Studio + SSJS works well.