#Pardot B2b Marketing Automation토론 중인 항목 34개

@Adam Erstelle makes sense! Can I add it as a conditional completion action in Pardot: "Assign To User" for Prospects that aren't already assigned and assign it to a Queue? I'd also like to add another conditional completion action on the same form to create a SF Task for those who are already assigned. Any concern here? 

One last item maybe you can help me with (related to this)… we’re hoping to implement something similar to this: https://mardreamin.com/course-video/how-to-report-on-and-reassign-qualified-prospects-from-pardot-manage-re-engaged-contacts-with-task-queues/ 

• Note: we’ll only have one Lead Queue to start. We plan on enhancing this process with scoring, updating Lead statuses, etc. but for now, this is where we’re starting. 

My question is around the “Re-Engaged” process + how we can possibly relate the form submission details to the Salesforce Task for “Re-Engaged” records. Also, to me, a “Re-Engaged” record could be a Lead or Contact (not all Leads convert right away and can sit in Salesforce, and we want to create a Salesforce Task to let Sales know if they “Re-Engaged” + not create a duplicate Lead record). The default behavior of Pardot is to not create a duplicate Lead record if a Lead or Contact already exists. If we were just creating Tasks for existing Contacts or creating tasks for every form submission (Lead or Contact), then that would be easier as we could say this on the autolaunched Flow: “If the related record is a Contact, then also create a Salesforce Task/relate the form submission detail to that. If it’s a Lead, just create the form submission detail and relate it to the Lead” or “For every form submission (Lead or Contact), create a Salesforce Task/relate the form submission detail to that”. The key here is that the initial Lead conversion + assignment from Salesforce is enough as we’ll assign them to a Lead Queue and a Task really isn’t needed here (will create more admin. work (the team will have to manage the Lead Queue + SF Task Queue and decipher the new Lead created and find the related SF Task assigned to a Queue - both were created for the same reason) + it’ll be harder to decipher “Re-Engagements” vs. new Leads conversions). The solution I provided above ( https://mardreamin.com/course-video/how-to-report-on-and-reassign-qualified-prospects-from-pardot-manage-re-engaged-contacts-with-task-queues/) uses a Completion Action to create a Salesforce Task for each form submission, so it's not really only for Contacts (re-engaged as they state). If a Lead submits a form again with that Completion Action, then a Task will be added to the Queue and if a new Lead submits the form, then a Task will be added to the Queue. In the end, I'm trying to create SF Tasks for records that already exist (Lead or Contact) and not new Lead assignments. The ideas I thought of were the conditional completion actions (if assigned vs. not assigned) directly on the Pardot form or use the form submission autolaunched flow. Thoughts?  

Thanks!

Hi Akshay - great write-up, and the good news is most of this traces back to one root cause (your #4), with #2 being expected behavior. Taking them in order: 

#4 first, because it explains 1 and 3: yes, the Incognito/private testing is absolutely skewing your data. Pardot identifies visitors with a first-party tracking cookie. Incognito starts with no cookie and throws it away when the window closes, so every private session looks like a brand-new anonymous visitor - and view/click tracking is often blocked entirely in private mode (and by ad blockers, Safari ITP, and Do Not Track). Submissions still record because a form post is a hard server hit, but the passive view/click pixels may not fire. That one fact drives most of the weirdness below. 

1. Views (3/1) lower than Submissions (7/5): this happens when the view pixel is blocked, or the page is served from cache, while the submission still records. Incognito plus repeated testing is the classic cause. Two other contributors: if you submit the form directly (or via an embedded/iframe form) instead of loading the landing page each time, the submission counts but the landing-page view doesn't; and a cached reload won't always re-fire the view tracker. Test in a normal browser without clearing cookies and the numbers line up much better. 

2. Score climbing on every resubmission: that's expected, not a bug. If you're scoring through the form's completion action (adjust score), it fires on every submission. The standard fix is to move that scoring to an Automation Rule instead - Automation Rules match a given prospect only once by default, so points are awarded on the first submission and not again on repeats. (Alternatively, zero out the per-submission points and lean on grading/engagement.) That gives you the 'first real engagement' behavior you're after. 

3. Two-button click data not matching: plain HTML links on a landing page aren't reliably attributed on their own. To measure which link people prefer, wrap each one in a Pardot Custom Redirect - each gets its own trackable URL and its own click count, so 'Click Here' vs 'Contact Us' becomes clean and unambiguous. (The same Incognito cookie issue was mangling the association here too.) 

For clean testing going forward: use a normal, consistent browser profile, don't clear cookies mid-test, use a dedicated test prospect with a unique email, exclude your internal/team IPs from tracking, and give Pardot a few minutes since activity processing isn't always instant. 

Do that and 1, 3, and 4 largely resolve themselves, and 2 becomes a one-time Automation Rule. Hope this helps!

1. User License: Our Pardot users currently have a Chatter/Chatter Free-type license. What license is actually required for Pardot Lightning access — will Chatter-licensed users work, or do they need to be upgraded first? 
   If you are referring to an "identity" license, these still work, but it still retains the limitations in that you can't access certain necessary features, like Salesforce campaigns. Ideally admins should have full salesforce licenses. 
2. Pre-Migration Checklist: What key things should we check or prepare before starting the switch — any pre-migration steps people often overlook? 
   Normally what trips people up is getting the visibility of the app to the correct profiles.  Follow the setup instructions carefully.  Also the user/role mapping if you migrate Account Engagement user management to Salesforce is quirky.  You still map profiles to roles in AE, but there's a whole different mapping in Salesforce. This article has some good tips.  
3. Existing Assets: Will our current email templates, forms, prospects, scheduled email for campaigns, and email domains carry over automatically, or do some need manual migration? 
   There's really no change. It's just looking at the same data in a different interface. However, going on lightning also gives you access to the new CMS, landing page and email builders (which also have to be configured and access given to your users). These are in addition to, not replacing, the current Pardot resources. 
4. Sales Cloud Impact: Does this migration affect our existing Sales Cloud (Lightning) production data in any way? 
   Only that there's a new Account Engagement App for the people that use it. 
5. Classic Access Post-Migration: After Lightning is set up, will pi.pardot.com (Classic) still be accessible, or is it fully deprecated at that point? 
   Yes. 
6. Nonprofit Cloud Compatibility: Is Pardot Lightning compatible with Nonprofit Cloud orgs? Does the setup/migration process work the same way as it does for a standard Sales Cloud org?  
   I would think so but I am not certain of that. 

hello  

I find this articles 

may be it's going to help you. 

regards

Hi @Sam Vanrintel

appreciate the response here!  

The other item to note about forcing MCAE/SF to generate a new Lead (always) is that this will create duplicate records, which will split engagement data + can create a mess quickly (if Sales isn't merging records correctly)  

Yeah... I think this is the last missing piece for Campaign Influence. Campaign Influence will never be perfect and to me it's used more for trends, but to me this is a big missing piece. I thought of updating the Campaigns regularly as well, but that creates more admin. burden/risk of missing one (I will note that sites can have many generic pages with request more information/consultation forms that sit for a while) + isn't the 100% solve as we could get Prospects submitting the same form multiple times before we create a fresh campaign and associate it to the content.  

The Flow is a good idea to automatically create new campaigns for  "always on" campaigns. We'd just need to remember to associate the new campaigns to the applicable content in MCAE.  

One idea I have is to create SF Tasks from MCAE. With that, use External Actions to create a File/Note on the task of the form submission + define the task subject line (use a Flow). Then, we align the task status field (or custom field) that Sales uses to work the "re-engagement". If the status/custom field reaches a certain stage, then an Opportunity is automatically created using a Flow + the task is related on the activity. With using naming conventions, we can report on Activity (Tasks/Subject Line) + Opportunities. We would then use both Campaign Influence + this Task reporting to get the full view.  

Another possible idea would be to send the campaign information when the External Action is executed in MCAE and associate it to the SF Task using a custom field, then the campaign could be auto-populated on a custom field on the Opportunity if the specific status/custom field reaches a certain stage on the Task. With this set-up, the custom campaign field on the Opportunity works the same way as the PCS model, but we include a time frame on the custom field to make this more accurate as the PCS field takes whatever campaign is the most recent create date.  

Added this to the IdeaExchange -

Thanks!