This article explains steps you can take to investigate issues with Leads tasks that have a method of API.

For Sales API tasks, see the appropriate vendor article, such as CDK DMS.

Investigating API QA Issues

1. Are there a full range of dates in the data loaded?
2. Verify an API Key (& ID if necessary) have been entered on the corresponding property in the DMUI -> Data Management -> Properties -> 3rd Party page.
3. If the dealer is new, verify the API key against the one that the vendor sent us in an email.  Make sure they match.
4. Verify the key Status is set to Active.
5. If a Validate button is available, click Validate to verify the key works/is correct.
6. Check the Jobs Server Logs for the specific API DAG and search for the property name or API Key. See if there are any error messages.
   1. If we are not receiving data or there are errors, contact the data vendor.  See Vendor Details & Contact Information.

This article explains steps you can take to investigate issues with tasks that have a method of Automated Report. 

Investigating Automated Report QA Issues

1. How Automated Report Data Is Loaded:
   1. 🚦 Older clients using VinSolutions CRM and VinSolutions Call Tracking automated reports that are received on the 1st of a month are automatically loaded into Dropbox IDD by the following Make scenarios:
      1. Dropbox - VinSolutions CRM (Gmail --> Dropbox)
      2. Dropbox - VinSolutions CT (Gmail --> Dropbox)
         (Newer dealers using VinSolutions are setup on Wall-E using the SCRAPER method.)
   2. All other vendors - Reports are sent to DataTeam email and must be manually loaded to Dropbox IDD, then set the task to Done or DMS Done.
2. Check Datateam Inbox to see if the report was received.
   1. If the report was not received, login to the vendor system and verify if the report still exists and the schedule is set up. Test the schedule to see if the report is delivered.
3. If login issues, address with the client, CCing the CSL, and place the task status in CSL/Dealer Stuck.
4. If VinSolutions CRM and there is a large number of rooftops included, you may need to split into multiple reports (duplicate report; rename to '1 of 2" and "2 of 2". Set subscription for one report to half of the rooftops, set subscription for the other report to the other half of the rooftops). It is best to set these type of dealers up on Wall-E to avoid this issue.
5. Check the appropriate Dropbox Data Archive to see if the file was loaded.
6. If a (multi) file, check claripedia.property_aliases table to verify the aliases are mapped to the correct Property IDs.
7. Check leads_raw or sales_raw, searching by source_document, to see if the data was ingested.
8. Check sales.sales_filtered or sales.leads_filtered to see if data was filtered out.

This article explains steps you can take to investigate issues with tasks that have a method of Collect or Download.

Investigating Collect QA Issues

1. If a problem with lead files we loaded, review the files we loaded in Data Archive
   1. If the file is still in Insyncing Data Drop:
      1. Check Slack channel #sales-leads-processing for errors
      2. Ask Ops Specialist to check Jobs server logs for preprocessing errors
   2. Make sure all data is there:
      1. no missing days (a full range of dates)
      2. no missing columns
      3. data is populated in all columns (not blank)
   3. See Master Clarivoy Data Input Requirements for general column requirements, then check Vendor Details & Instructions board for vendor specific columns
   4. Make sure all data in the rows line up with the column headers
   5. Occasionally an improperly formatted CSV file (due to a vendor system issue) may cause data to line up incorrectly.
   6. CSV files can be generated or saved improperly by some systems/users. If you open Excel and see a message in a cream colored bar at the top of the sheet referencing the data being in .TXT format, resave the file using Save As and select CSV UTF-8 (Comma delimited) (.CSV) as the file format.
2. You may need to pull a new file if the data was not pulled correctly the first time. If this is the case, let the Ops Specialist know to delete out the old file from the database first.
   See also:
   1. Deleting a Sales File
   2. Deleting a Leads File
3. If you see this error in the preprocessing error log:
   ERROR 4122056 : field larger than field limit (131072)
   the contents of one cell has exceeded the max field size for a .CSV file. Resave the file as a .XLSX
4. If it is a new vendor, ask Ops Specialist to verify it is mapped correctly.
   See also:
   1. Mapping Leads Files
   2. Mapping Sales Files 
   3. Mapping Multi Files 

Investigating Download QA Issues follows the same steps as Collect QA Issues.

This article explains steps you can take to investigate issues with tasks that have a method of DVSFTP (DealerVault SFTP).

Investigating DV SFTP Sales Count Issues

If Sales Counts look low for any client on DV SFTP:

1. Ops - Check Looker Sales Counts Verification board
   1. Ops - If we DO have the current calendar month's data (we are showing Sales Counts for the month after the P Month we are working on), then DealerVault is receiving current data from the client and is delivering it to us.
      1. Ops - Note the issue in the conversation updates & tag the CSL. Ask the CSL to verify Sales Counts with the client.
      2. Ops - Set the task status to CSL/Dealer Stuck.
   2. Ops - If we do NOT have current calendar month's data:
      1. Ops - Take a screenshot of the Sales Counts Verification board. In an update on the Monthly Task item, paste the screenshot and tag the CSL. Let the CSL know that we are missing data after a certain date. If the account does not have a CSL, tag the CS Specialist.
      2. Ops - Set the task status to CSL/Dealer Stuck. (We are not using DealerVault Lagging Stuck yet as we do not know if it is a lagging feed at this point.)
      3. CS - As of January 2026, it is the CS Team's responsibility to investigate and open tickets for Lagging DealerVault feeds and follow up on them. Follow steps in Investigating DealerVault Lagging Feeds.

Investigating a DealerVault Data Mapping Issue

1. Ops - If needed, we can check the files we received from DealerVault
   1. The actual sales files for any client on DV SFTP can be found in Clarivoy's SFTP server under:
      dealervault/to_clarivoy/done
      The filename will start with the property ID, followed by an underscore, then the date the file was sent in YYYYMMDD format. Example: 49445_20220706_0724_SL.csv
2. You can also open a DV Ticket to request help or an investigation from DealerVault Support.

DV Data Mapping

• DealerVault's mapping from DMS fields → DealerVault files can be found in the article How We Count Sales
• DealerVault mappings (DV file columns → sales_raw) can be found here:  https://github.com/Clarivoy/data-server/blob/master/sftp_integration/helper_modules/dealervault_sales_helpers.py

This article explains steps you can take to investigate issues with tasks that have a method of Scraper.

Investigating Scraper QA Issues

If we have zero or low leads or sales counts:

1. Check Slack channel #wall-e_alerts for any alerts for the current dealer.
   1. See Wall-E Troubleshooting Issues
2. Verify the login still works.
   1. If a password change is required, make sure to update the Wall-E dealer profile in the Wall-E Onboarding Site.
3. Verify we still have the correct permissions to pull the data (try to manually pull it and see what you come up with).  If we have permissions but no/little data comes up, the dealer has likely changed vendors.  Tag the CSL and CS Support Team to notify them of the issue and request they ask the dealer if they have switched vendors.
4. Verify the store setup is still the same in the CRM (stores have not changed names)
   1. If needed, you may need to update the Wall-E dealer profile in the Wall-E Onboarding Site.
5. If data appears correct in the CRM but not in Looker, check property alias mappings.  See:
   1. Mapping Leads Files
   2. Mapping Sales Files 
   3. Mapping Multi Files 
6. You can check the data that is being downloaded by Wall-E by looking in the Wall-E Archive in Google Cloud Stroage.
   1. If data appears in the CRM but there are no files for the dealer in the archive cloud storage, the steps to pull the data may have changed in the CRM and Wall-E needs a code update.  In this case, open a ticket for the Nix team to update Wall-E code on the Tickets Board.

This article explains steps you can take to investigate issues with tasks that have a method of SFTP. 

Investigating SFTP QA Issues

1. Check the corresponding SFTP folder to see if there are any files that have not been moved to "done"
   1. This would indicate that either the property is not setup in the DAG code
   2. OR the DAG has not run for the scheduled timeframe yet
   3. If we are not receiving data for this dealer, contact the vendor support (or client if the client is the one sending the data)
2. Check Airflow to ensure a DAG has been setup (if a new vendor).
   1. If not, check to see if there is a ticket open on the Tickets Board.
3. Check Airflow to ensure the property has been added to the appropriate DAG code.
4. Check Airflow run logs for any errors.
5. Check the corresponding Dropbox Insyncing Data Drop folder and/or Slack #sales-leads-processing to see if files are stuck there.
6. If we are not receiving data or there are errors, contact the data vendor.  See Vendor Details & Contact Information.  If it is a client-specific SFTP integration, the contact should be listed on the task Notes or Updates on the Monthly Tasks board.

DealerVault SFTP Troubleshooting

DealerVault integrates through SFTP, but has its own separate troubleshooting - see DV SFTP QA Issues.

Reference this article if you have a dealer who says the Total Gross values or Total Revenue (sale price) displayed in the DMUI do not match their calculations.

9 times out of 10, the issue is comparing “apples to oranges".  Read on to find out what our Dashboard data represents, where we pull the Gross values from, and how to ensure the dealer is comparing to the exact same fields & calculations that we use.

MTSA Pro and Pro+ Dealers

Where We Get Gross Values From

To see which Gross fields we take in for each DMS, see How We Count Sales.  Reference the “Gross Fields” column.

Gross Values in the Dashboard Data

• Executive Summary 
  • Total Gross - Sum of the “Total Gross” column on all Sales taken from the DMS.  
    • If the DMS or sales file does not provide Total Gross, we calculate this using Front Gross+Back Gross.
    • This may not match what is shown on the ROI Audit page.
• ROI Audit
  • Total Sales Revenue on the ROI Audit page is the sum of the Sale Price on Sales from the DMS.
  • Total Gross on the ROI Audit page is calculated as Front Gross+Back Gross=Total Gross.
  • If your DMS uses a custom formula to calculate Total Gross (such as factoring in Commission amounts), that will not be reflected here.
    • Because this is calculated and not pulled directly from the DMS, the values may not match what is shown on the Executive Summary page under Total Gross.

Troubleshooting Steps

If a dealer's Total Gross values do match those shown in our DMUI, there can be several causes.  Please follow these steps to investigate.

1. Verify that the dealer's Sales Counts for the month match what we are showing in Sales Standardized.  Remember the dealer needs to exclude any B2B Sales from their counts.
   1. Use this article to help verify their sales counts: Verifying Sales Counts 
      1. If there is a discrepancy in sales counts, we need to resolve that first before exploring any Gross mappings.  For steps to investigating, see: Sale Count Discrepancies 
      2. If the sales counts match closely enough, proceed to the next step.
          
2. Determine exactly what data you are looking at in the Dashboard.  This is important so that you make sure you are comparing "apples to apples".
   1. Executive Summary page - the dealer should compare to the “Total Gross” field we take in from their DMS
      1. If they are a Collect, refer to the file to see if a Total Gross column exists.  If no Total Gross column exists, our system will add Front Gross + Back Gross from the collect file.
   2. ROI Audit page - 
      1. Total Gross:  the dealer should add together the Front Gross + Back Gross values that we take in from their DMS to get a number to compare with.  The Total Gross on the ROI Audit page may not match the sum of their “Total Gross” from their DMS if they are using a custom Total Gross calculation that factors in other numbers besides Front Gross + Back Gross.  (Some dealers factor in Commission when calculating Total Gross.)  There is no way around this / to make it match on the ROI Audit page, even if the dealer were to go Collect - because of how the ROI audit page is coded.  It is Front Gross+Back Gross=Total Gross.
      2. Total Revenue:  The dealer should add together the Sale Price column from their DMS.
          
3. Verify how the dealer is pulling their $ amounts
   1. Verify the Source - The dealer needs to pull their sales counts from the same source we are using - usually their DMS (occasionally the CRM).  The dealer cannot use financial or accounting reports that do not come directly from their DMS.  Check the dealer's DMS task on the SA + TVA Ops Monthly Tasks board to find where Clarivoy is sourcing the dealer's sales data.  
       
   2. Which Gross fields is the dealer looking at?
      The dealer needs to pull their gross values using the same fields we are using and compare to the same sources we are using.
       
4. Verify how Clarivoy is pulling their $ amounts
   1. Determine What Gross fields we take in from their DMS - To see which Gross fields we take in for each DMS, see How We Count Sales.  Reference the “Gross Fields” column.  If a DMS is not listed on this chart and we are pulling their sales from DealerVault, you can ask Ops Team to request the DMS-specific mappings from DealerVault to find out which fields we map for Sale Date, Front Gross, Back Gross, and Total Gross.
   2. If only one field is missing (Front Gross or Back Gross) in the sales data:
      1. if Back Gross is missing, we calculate back_gross = total_gross - front_gross
      2. if Front Gross is missing, we calculate front_gross = total_gross - back_gross
   3. If both Front Gross and Back Gross are missing but Total Gross is not:
      The total_gross values get put into front_gross by the sales processing DAG.
      front_gross = total_gross
   4. Total Gross Missing from sales data: If Total Gross is missing from the sales data, it is not calculated in sales_raw, but calculated by the Dashboard code.
       
5. If the Gross fields Clarivoy is using do not match what the dealer wants to use:  If the dealer wishes to use a different gross field than what is listed for the DMS:
   1. CDK API - We can custom map fields.  (For more information on CDK custom mappings, see CDK Integration.)  Look at CDK Raw and determine the Gross field the dealer wants to use, then open a ticket for Ops Tickets Board and include:
      1. The property name(s) and ID(s)
      2. The name of the DMS field(s) and the name of the Clarivoy Sales Standardized fields you want them mapped to
      3. Which month(s) you want data corrected for
      4. Is now a good time to perform the data correction?  (If you have an upcoming meeting and need us to wait, specify when you would like the correction performed)
   2. Tekion SFTP - We cannot custom map fields if the dealer is using our Tekion DMS integration.  They will need to switch to uploading a Sales file every month (COLLECT).  Ensure that all 3 gross fields appear in their file and that you map them properly.  Follow the process here: Changing Task Methods: Switching from an Integration to Collect.
   3. DealerVault - We cannot custom map fields if the dealer is using DealerVault.  They will need to switch to uploading a Sales file every month (COLLECT).  Ensure that all 3 gross fields appear in their file and that you map them properly.  Follow the process here: Changing Task Methods: Switching from an Integration to Collect.
   4. Wall-E pulling sales from CRM - Many CRMs do not provide Gross values on Sales.  In CRMs that do provide Price and Gross, the data is often times largely incomplete (values are blank on many sales, or the amounts do not match what is in the dealer's DMS).  
      1. No Gross values available - If we are not receiving Gross values from the CRM, the dealer will need to upload a Sales file to us each month instead in order for us to receive the Gross values.
      2. Dealer wants a Custom Mapping - If the dealer wants a custom Gross mapping, we cannot custom map fields if we are pulling Sales from the dealer's CRM using Wall-E. They will need to switch to uploading a Sales file every month (COLLECT).  Ensure that all 3 gross fields appear in their file and that you map them properly.  Follow the process here: Changing Task Methods: Switching from an Integration to Collect.
   5. Collect Files - We can set up custom mappings for each property's Collect sales file.  Check with Ops Team to see what the existing mappings may be for a specific property or to request an update to the mappings.  Please Open a Ticket on the Tickets Board for the Ops team to request the current mappings or any changes.
       
6. Requesting an Investigation from the Ops Team: After following all troubleshooting steps listed above, if you cannot determine the cause of the Sale Price or Gross Values Discrepancy, Open a Ticket on the Tickets Board with Category=QA Issue: Price or Gross and provide all of the following information:
           ALL ANSWERS ARE REQUIRED FOR OPS TO INVESTIGATE!
   1. What property is affected?
   2. What month's data is in question?
   3. Do the dealer's sales counts match ours?  (If no, STOP and complete a Sales Count Discrepancy investigation instead - see https://clarivoy.helpjuice.com/sale-count-discrepancies )
   4. What method are we using to collect the dealer's Sales?  (DealerVault, CDK API, Tekion SFTP, Collect file, Scraper from CRM)
   5. For each field being disputed, provide the dealer's total sum for the month:
          - Front Gross = 
          - Back Gross = 
          - Total Gross = 
          - Sale Price = 
   6. For each field being disputed, provide the name of the DMS or CRM from which the dealer sourced their data:
          - Front Gross = 
          - Back Gross = 
          - Total Gross = 
          - Sale Price = 

Source Reports Dealers

Collect:  Data counts come directly from the dealer provided sales file.  

1. First, verify that Sales Counts in Sales Standardized match what the dealer is expecting.  Remember, B2B Sales are filtered out.
2. Verify the mappings used for the property's Collect sales file and confirm that we are mapping the columns that the dealer wants.  If necessary, correct the mappings, then you can delete and reload previous data up to 90 days back.

Scraper:  Dealer provides us a login to their CRM and we pull the sales from their CRM using our Wall-E Scraper process.  Every day we pull the previous 5 days and perform “Sales Row updates” using the newest versions.

1. First, verify that Sales Counts in Sales Standardized match what the dealer is expecting.  Remember, B2B Sales are filtered out (IF their CRM includes a Sale Type field; if not, we use customer name filtering to filter B2B sales but it is not 100% accurate due to variations in names).
2. There are other potential issues that could cause Gross or Sale Count discrepancies when pulling sales using the CRM Scraper, including, but not limited to:

• No Gross values available - If we are not receiving Gross values from the CRM, the dealer will need to upload a Sales file to us each month instead in order for us to receive the Gross values.
• Dealer wants a Custom Mapping - If the dealer wants a custom Gross mapping, we cannot custom map fields if we are pulling Sales from the dealer's CRM using Wall-E. They will need to switch to uploading a Sales file every month (COLLECT).  Ensure that all 3 gross fields appear in their file and that you map them properly.
• Blank VINs - Often times CRMs include sales with no VIN number.  Clarivoy does not take in any sales without a VIN.  (This is because the VIN is used to “dedupe” sales data)
• Date changes - If a dealer enters a sale, then later changes the date on that sale,  both entries count as Sales in the dealer's data.  We have no way of identifying that the new date is a sale that was changed (instead of just the same car being sold multiple times within a month).  We dedupe based on same VIN, same Sale Date, same Property ID.
• Data updates > 5 days after finalizing sales - We only receive updates on sales for the first 5 days after the sale is entered into the CRM.  If the dealer is updating sales more than 5 days after the sale was first entered, we will not receive the updates.  The dealer should switch to providing a COLLECT file instead in this case.
• Dealer is slow to finalize sales - We pull the most recent 5 days of sales every day from the dealer's CRM.  If a dealer takes more than 5 days to finalize a sale, we will not receive it.
• B2B Filtering - Most CRMs do not have a Sale Type field to indicate if a sale is a B2B sale.  If there is no Sale Type field, we attempt to filter B2B sales using the Customer Name.  It's possible we are filtering out sales as B2B but the dealer is including those in their CRM sales count.

MTSA Pro and Pro+ Dealers

If a dealer's New and Used RETAIL sale counts do match those shown in our DMUI Executive Summary page, there can be several causes.  Please follow these steps to investigate.

1. Check to ensure we have a full range of data for the month - check line chart Sales by Day on the Sales Dashboard to ensure we have sales for every day of the month (often times dealers are closed on Sundays and Holidays, but we should have fairly consistent sales otherwise - compare to prior months)
   1. This is a typical issue for new CDK API clients. We may need to run CDK backdata for a specified date range if we are missing data.
       
2. Verify how the dealer is pulling their sale counts:  
   
         2a.  Source - The dealer needs to pull their sales counts from the same source we are using - usually their DMS (occasionally the CRM).  The dealer cannot use financial or accounting reports that do not come directly from their DMS.  Check the dealer's DMS task on the SA + TVA Ops Monthly Tasks board to find where Clarivoy is sourcing the dealer's sales data.  
   
         2b.  Date Field - The dealer needs to pull their sales counts using the same date field we are using (see decision tree below).  If the dealer wishes to use a different date field (such as Delivery Date), they need to switch to sending us a Sales file every month (COLLECT).   
    

3. Check to see if the Dealer is marking B2B Sales - Is the dealer properly identifying B2B deals in their DMS Sale Type field?  
    

Other Causes for Sale Count Discrepancies

• If DealerVault, Tekion,or CDK API: Dealer may be changing Sales Date after the sale was first set to a Finalized Status. We take in the first date it was set to Finalized.
  • CDK API - FiWipStatusCode = F [for Finalized]
  • Tekion - Deal Status = CLOSED_OR_SOLD
  • DealerVault - varies by DMS. You would need to open a DV ticket to find out.
    • If DV or CDK pushes the sale again, we would have duplicates
    • If DV or CDK does not push the sale again, we would have the sale under the original date. If it is in a different month than the new date, our counts could be off vs. the dealer's
• If DealerVault, Tekion,or CDK API: Dealer may be including other deal statuses besides Finalized in their counts. See criteria below based on DMS. If the dealer wants to include any deal statuses besides Finalized deals, they must switch to providing Collect sales files.
  • For CDK API, we only count deals where FiWipStatusCode = F [for Finalized]
  • For DealerVault, we only count deals where Deal Status is marked as follows:
    • ACS = F
    • Advent = CLSD
    • Automate = C
    • AutoSoft = 1
    • DealerBuilt = CLOSED
    • DealerTrack = U
    • Reynolds & Reynolds = F
  • For Tekion, we only count deals where Deal Status = CLOSED_OR_SOLD
  • For Collect files, we count ALL deals provided in the file
• If DealerVault, Tekion, or CDK API: We do not have all of the DV Feeds or CDK Subscriptions setup for a particular store. Sometimes stores will have more than 1 DV Feed or CDK Subscription per store, especially if they are a combo brand (e.g. Hyundai Genesis may have 2 separate DMS feeds)
• If DealerVault, Tekion, or CDK API: Dealer could be sharing a DMS with another store and we are getting too many sales.
  • Check Looker Sales Dashboard - Sales Standardized Vehicle Make Summary. See if there are new vehicles for a make that does not correspond with this rooftop.
  • DealerVault - If the dealer has a custom field where they are denoting which rooftop/store each sale belongs to, DealerVault has the ability to filter the sales by that field. We just need the name of the field, the values and their corresponding stores. You will need to:
    • 1. Open a DV ticket and ask them to filter for only the sales we need
    • 2. Once DV has made that change, delete out all existing data we have
    • 3. Then ask DealerVault to repush all data back to the Start Date
  • If CDK API - There is no way for CDK to split out sales within 1 subscription. Dealer will need to go COLLECT and provide a manual sales file each month.
  • Tekion: Not sure if they can split stores - email Tekion Support to inquire [update this process doc and Vendor Details board if we find out the answer]
• Sales are coming through with missing information (No PII, No VIN or Invalid VIN) - these would get filtered out. Verify by looking at the sales file.
• Dealer is including other deal statuses besides Finalized in their counts -
  See criteria below based on DMS. If the dealer wants to include any deal statuses besides Finalized deals, they must switch to providing Collect sales files.
  • For CDK API, we only count deals where FiWipStatusCode = F [for Finalized]
  • For DealerVault, we only count deals where Deal Status is marked as follows:
    • ACS = F
    • Advent = CLSD
    • Automate = C
    • AutoSoft = 1
    • DealerBuilt = CLOSED
    • DealerTrack = U
    • Reynolds & Reynolds = F
  • For Tekion, we only count deals where Deal Status = CLOSED_OR_SOLD
  • For Collect files, we count ALL deals provided in the file

Requesting an Investigation from the Ops Team

After following all troubleshooting steps listed above, if you cannot determine the cause of the Sale Count Discrepancy, use this form to request an investigation from the Ops Team:  Sale Count Discrepancies Investigation Request

Source Reports Dealers

Collect:  Sales counts come directly from the dealer provided sales file.  B2B Sales are filtered out.

Scraper:  Dealer provided us a login to their CRM and we pull the sales from their CRM using our Wall-E Scraper process.  

If the dealer chose to provide a login, we pull from your CRM.  Every day we pull the previous 5 days and perform “Sales Row updates” using the newest versions.

• If a sale is not entered in your CRM within 5 days of the sale, we will not receive it.  If you batch or delay entering sales, you may want to consider uploading a Sales file to us each month instead,

This article explains common causes for Offline Attribution counts being low or zero and steps you can take to investigate and troubleshoot.

Possible Causes for Low Offline Attribution

Issues on both ends

• Sources classified as channel=internal
• Clients need to mark correct sources
• CSLs need to review all sources currently classified as internal

Issues on client’s end

• Lead Sources have dropped or disappeared from their CRM (typically due to a dealer ending a marketing campaign or relationship with a particular vendor)
• Wholesale & Fleet sales marked incorrectly
  • Many sales marked incorrectly as “Retail”
  • Some clients using incorrect field - marking “Fleet” or “F” in new_or_used instead of sale_type (often times the client is doing a mixture of both, leading me to believe this is a bad behavior for select salespersons)
• Lead Sources blank in CRM
• Low Sales with Phone %
• Low Sales with Email %
• Low Completeness Score of Leads
• Client changed data vendors and did not notify us to update the mappings
• Client manually changing column names in their files so they are not consistent from month to month

Issues on Clarivoy’s end

• Property Setup Incorrectly
  • PRO/PRO+: SA Dashboard Visible = False (If this is the case and you correct this, also make sure Visible In Dropdown=True) OR SA Dashboard Visible was set to FALSE at the time the Sales and Leads files were loaded, but has since been corrected.
  • STARTER/BASIC: Source Reports = False (If this is the case and you correct this, also make sure Visible In Dropdown=True) OR Source Reports was set to FALSE at the time the Sales and Leads files were loaded, but has since been corrected.
• Bad Data Loading / Data Quality Issues - typically caught before this point
  • Sales or Leads not loading correctly (processing / mapping issues)
    • Check Sales with Phone % on Prelim QA Looker board
    • Check Sales with Email % on Prelim QA Looker board
    • Check Sales Schema Mapping table and Sales Schema Mapping Custom Headers table to ensure the file is mapped correctly. See Looker board: Sales Mapping
    • Check Leads Schema Mapping table and Leads Schema Mapping Custom Headers table to ensure the file is mapped correctly. See Looker board: Leads Mapping
  • Wrong date ranges, or incomplete dates - Download errors on either Clarivoy or Client end
  • Wrong store data loaded - Download error on either Clarivoy or Client end

Process for Investigating Low Offline Attribution

1. Check that the Property is setup correctly.
   1. Login to the DMUI
   2. Data Management
   3. Properties
   4. Search for the property
   5. Edit
   6. Check that SA Dashboard Visible = True (or if Starter, then Source Reports=True). If it is False, this is the cause for no Offline Attribution. If this is the case and you correct this, also make sure Visible In Dropdown=True. After correcting this, you will need to either (A) Reprocess SA Matching or (B) Delete & Reload their Leads and/or Sales files in order to get the matching to occur.
2. Go to the Offline Matching Investigation Looker board.
3. Set Filters
   1. Enter the Property ID in the filter.
   2. Enter the Property IDs for all other properties within the client group in the 2nd filter. Make sure to include the Parent Property ID as well.
   3. By default, filters are set to look at the most recent 3 complete months.  If the period in question is different, adjust the date filters accordingly.  
      1. Matching Sales Date is the month you are concerned about attribution for.
      2. Trend Dates should start at least 2 months earlier than the Matching Sales Date.
4. Review the Matched Sales with Leads section
5. Review the Unmatched Sales section
   1. Look for B2B sales where the Sale Type was not marked correctly (wholesale or fleet not marked as such). Dealers not marking B2B sales correctly can lead to lower offline attribution % vs. if they had marked the sale types correctly.
6. Review the Unmatched Leads section
   1. Look for CRM and Chat leads with blank Raw Source values.
      Look for Call Tracking leads with no campaign information at all (no campaign phone number and no campaign name).
      None of these leads would be used in matching.
      1. If all Raw Source values are blank for all leads for a particular data supplier, this could indicate a potential mapping issue. Notify Ops Team.
      2. If a large number (but not all) of Raw Source values are blank, this is a problem. The dealer is not marking Lead Sources correctly in their CRM, or the leads are not importing correctly into the dealer's CRM. We are unable to use any of these leads in matching.
   2. Look for raw source and raw source detail combinations that ARE classified as Internal (see looker board below for a quick reference list) but perhaps should not be
   3. Look for sources that are NOT classified as internal but probably should be
7. Review the OFFLINE ONLY Attributions section
   1. If there was a drop in attribution at a particular point, adjust both Date filters to 2 months prior to the drop point (so we can look at trends from prior to the drop and after the drop).
   2. Sort Sales Matched descending (largest numbers at the top) by the earliest month
   3. Look for downward trends where Sales Matched counts decline as the months progress.  Any trend like this indicates that a particular Lead Source is no longer appearing, or appearing more infrequently, in the dealer's offline leads (typically CRM).  (Ignore sources that would be classified as channel="internal" such as “Walk In”, “Phone Up”, “Internet”, “DMS”, etc.).  Reasons for downward trends in Sales Matched can include:
      1. Dealer has ended a particular marketing campaign
      2. Dealer has ended a relationship with a particular vendor
      3. Data connection for that vendor's leads is no longer working (the data is not flowing from the lead vendor into the dealer's CRM)
         All of these above reasons are are out of Clarivoy's control and point to things that the dealer would need to investigate.
8. See Internal Classifications on Looker board - CSL should review sources classified as channel=internal to make sure these look correct. Sources that are classified as channel=internal are suppressed and not used for attribution. Having sources incorrectly classified as internal can lead to lower Offline Attribution.

See Also

• Offline Matching Queries and Statements for PostgreSQL 

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: