https://clarivoy-squad.monday.com/docs/2450180928?blockId=b9606511-8fed-43fb-b324-c9146fbf543a

LFI are Clarivoy web form leads which are collected by our Clarivoy Website Tag.  They appear in the Leads Raw and Leads Standardized tables alongside other traditional leads like CRM, Call Tracking, etc.  This article explains steps you can take to investigate QA issues with LFI Leads.

Investigating LFI Leads QA Issues

If there is a problem with Clarivoy/LFI leads missing or stopping after a certain date:

1. If Dealer is using a Website Compliance Tool (such as Comply Auto), we may not get LFI due to recent changes Comply Auto made in their website code (they are considering Clarivoy a "retargeting cookie" so if the user hits Decline or "Essential Cookies only", our tag will not load. 
   1. We are revising pieces of our code (removing the parts related to Audience Booster so that we will not be considered a "retargeting cookie" and will ask Comply Auto to recategorize our cookie as "analytics" which means it will always load - but this is still WIP). This is a known issue that Engineering is working on but has not yet been resolved. 
   2. For a list of dealers using Website Compliance Tools, see the Clarivoy Properties board - there is a "Website Compliance Tool" status field
2. Using the Clarivoy Tag Assistant Chrome Extension, Verify the tag is on the website and shows green.
   1. If tag is on the website but has a red box, it could be an incorrect client name or client ID.
   2. If tag is missing, notify CSL and leave in QA Issue until CSL approves moving on.
3. Verify that the tag assistant shows the correct client name (matches client name in the DMUI - check the actual client name, not the display name and beware of slight variations)
   1. Copy client name from tag assistant green box
   2. In DMUI Data Management → Clients search box, paste the client name.
   3. Click Edit
   4. Verify that the property (and correct Property ID) is listed in the table under this client.
4. Verify that the correct domain is entered on the property in the DMUI (pay attention to domain extensions - .com, .net, etc.)
5. Verify that the LFI flag is set to TRUE for the property in the DMUI
6. Check leads_raw to see if there are any leads for the specific property_id with lead_data_provider='Clarivoy'
7. Check that the client ID matches the expected ID in leads_raw or leads_standardized for the Clarivoy leads
   (if a client name, ID, or tag were changed at some point, this could be the cause)
   1. Open https://clarivoy.cloud.looker.com/dashboards/79
   2. Filter for Property ID=the property in question, Lead Data Supplier=Clarivoy, and adjust time frame so you get some leads displayed
   3. Look at the Client ID column in the Leads Standardized table & compare to the DMUI (see next step)
   4. In the DMUI → Data Management → Clients, search for the client and click Edit. The Client ID is listed on the edit page.
8. Check that forms exist on the site (typically under Contact Us).  If there are no forms, there is no way for us to collect LFI leads.
9. Check if forms are located inside iFrames or Pop-Ups (where the forms are not hosted on the actual domain).
   1. Pop-Ups: In Chrome, right click, View Page Source. Verify the domain is the same as the dealer's domain on the property.
   2. Check for iFrames: In Chrome, right click on form page. If "View Frame Source" is an option, it is in an iFrame. Choose "View Frame Source" and verify that the domain is the same as the dealer's domain on the property.
   3. If forms are located on a different domain, notify the CSL and move on to Automatch. There is nothing we can do about this, unless it is a domain that the dealer owns and can place our tag on.
10. See Technical troubleshooting for form fields below.
11. If none of the above explain, tag the CSL and notify them. Let the CSL know you have checked everything possible and cannot determine the cause. If they wish for Engineering to investigate further, they need to open a ticket on the Tickets Board.
    In your notification to the CSL include:
    1. You verified the client name and ID are correct
    2. You verified that LFI=TRUE on the property
    3. URLs where forms are located
    4. If forms are located inside iFrames or Pop-Ups on a different domain
    5. If you suspect a form field naming issue, note that
12. CSLs - If you wish further investigation into missing LFI, open a ticket on the Tickets board for Engineering to investigate. Specify the following:
    1. Property Names and IDs
    2. Domains
    3. What tag assistant showed
    4. If we had previous LFI, what date did it stop?
    5. What steps you took to investigate

Additional causes could be:

• Client has reduced traffic to their forms due to site redesign (forms are more hidden, not as easily accessible as before)
• If dealer has never had any LFI, they could have very low web traffic (check pageviews?)
• Misc. odd HTML/Java code issues that prevent our tag from detecting form submissions

Technical Troubleshooting for Form Fields

(Example for steponekiafortwaltonbeach.com)

1. Find a form somewhere on the site with an email and/or phone <input> (usually on each item on an SRP has a button to pop up a form)
   
2. Click the button, in this case, Check Availability. Enter data in the popup form (Tab OUT of the fields, but DON’T SUBMIT THE FORM YET):
   

3. (your phone and/or email should now be stored in cookies named pfe_p and/or pfe_e. _p stores the phone value _e stores the email value)
   
   Check for cookies in Chrome dev tools (ctrl-i or right-click page…Inspect) under the Application tab, under left-pane Storage…Session storage, select the current domain.
   In this sample case, we see the email is stored, waiting to be sent later:
   
4. So, if theres a problem, it’s mainly one of two things. Either:
   1. The email and phone <input> elements are NOT identified as email phone fields that we search for.
      Or
   2. the Check Availability button that pops up the form  is not named something we currently look for.
5. First, check b) to see how the button is named, either by id= or class= via Dev Tools under the Element tab.
   
   In this case the Check Availability button has a class of lightning-custom-cta and stat-button-link

In the Clarivoy-TD-Global-Wrapper -> lib/treasure.js repo, see if either of these names are button names we look for (the line that starts with [].forEach.call(document.querySelectorAll( - for now line 186
https://github.com/Clarivoy/Clarivoy-TD-Global-Wrapper/blob/master/lib/treasure.js : 

      [].forEach.call(document.querySelectorAll(".ddc-btn, a.set-price-alert, .dialogbutton, [data-toggle], dynamic-form-link, #send-myoffer-btnId, .cta ul li a, .link a, .cta-button, .gg-app, .cblt-button, .pricealert-button, .new_inv_pad, button.expanded.primary, .dialog, .e-price-link, .cui-button, .dh-iconf-email, .avt-widget-btn, .popup-overlay, .listing-row__contact, .eprice.dialog, .purchase-inquiry-button, .ginput_container_email input, .ginput_container_phone input, [data-cmp='emailOwnerCTA'], .CarcodeWidgetContainer, .eva-button, #send-my-offer, ul.nav li a.btn-primary, .price-btn .price-btn button, .slimEPrice, #contactUsButton, .roadster-btn, u-mt1 button, .talktous, .showpricingmodal, .css-1f4eng7-DealerButton, form.css-1h2rpxu-DefaultForm-defaultFormStyles-defaultPrivacyPolicyStyles-defaultEmailInputStyles, .css-1ib0bnv-commonStyle-default-primary-WrappedButton, .css-20qcuk-primaryButton-primary, .css-df0zse-ContentContainer, .css-3o8v4c-commonStyle-default-primary, .css-hse4q7-ContentContainer, .css-cbasuv-ContentContainer, .G10CWo, .css-17bmhaa-ZipcodeLink.ex6i5w11, .css-1qvgxt6-default-primary, .css-1u67pam-FlexForm.epnwnz20, input#makeModelRadioButton, input#lpRadioButton, input#vinButton, .jss129, .jss136, .jss141, .jss110, .jss138, .jss263, .jss65, .jss709, .jss312, .jss308, .jss131, .jss129, .jss389, .jss372, .jss527, .PrivateSwitchBase-input-135, .MuiGrid-root button, input[name='intendedUse'], input[name='hasReadConsent'], input[name='contact'], .demo-cta, .price-btn, .lightning-custom-cta, .srp-cta, .als-btn")
 

In this case, we’re good: lightning-custom-cta is a button we look for, so that’s not our problem. (We know that anyway because we saw the pfe_e cookie in Session storage) This means we scan for buttons with the class .lightning-custom-cta on page load and wire up an eventHandler to then scan the popup for email and phone fields after it’s clicked.

…Now, let’s check for a) - ensure that the email and phone <input> fields are recognizable as phone and email inputs.

We scan the dom and look for any inputs with ids, classes, names containing ‘email’ ‘phone’ or input type = ‘tel’ to know what values to save in Session storage to be posted later. In this case, they both qualify and aren’t a problem: