Data quality and conversion analysis
Your team may be struggling to reach contacts, receiving records it cannot use or seeing too few enquiries become sales. LeadScale’s analysis examines the data behind the problem to establish where attention is needed.
Needs approval
LeadScale examines programme data to identify problems affecting lead quality and conversion. That can include capture errors, processing results, routing and the outcomes returned by client systems. The purpose is to establish where records encounter problems and what needs to change, using the information available for the programme.
End
Find the problem while there is still a chance to correct it
In its work with Everest, LeadScale analysed data from the client’s capture forms and identified faulty phone numbers. Checking was then applied at the form, allowing people to correct their details as they submitted them.
The finding changed where the problem was addressed. The person completing the form had the opportunity to correct the number before a contact team tried to use it.
Our lead validation page explains the four checks run between capture and delivery, and how the order of processing is set for your programme.
Separate a data fault from a programme requirement
A failed record needs an explanation. The Engine records the checks applied and their results, providing a starting point for examining why a record did not pass.
A phone number failing verification raises a question about the contact detail. A record excluded by a programme filter may instead have failed a requirement about which records the client wants. Combining both into a rejected-lead total hides that distinction.
On programmes that deliver records against an order, reconciliation also establishes what was supplied against what was ordered. That is useful delivery information; understanding conversion requires the later outcome too.
Connect delivery with later outcomes
A record passing the required checks is not the same event as that record becoming a sale. To examine conversion, the programme needs information about what happened afterwards.
The client and LeadScale agree what the programme is trying to optimise for. Where you share outcome data, the Engine and connected systems can be configured around those outcomes.
On programmes set up for it, outcomes can return through connected systems: a sale in a consumer programme, for example, or a qualified lead or opportunity in a B2B programme. Which outcomes are available depends on the programme and the information those systems return.
Needs approval
The conversion and routing review examines where records were sent and which reached the agreed outcome. It uses the later information alongside the original processing record to investigate where progression stopped.
End
The technical data services page describes the connections needed to return those outcomes.
Define the question and the evidence it needs
A contact team that cannot reach people needs a different investigation from a sales team that reaches them but finds no opportunity. Before starting, the question needs to be specific enough to establish which records and results will help answer it.
For capture quality, that may be the submitted details and the check results. For conversion, it also means identifying the later outcome being examined and whether that information is available. This determines what the analysis can establish and which questions remain open.
Findings that inform the next change
Needs approval
The findings connect the problem to the evidence behind it and identify where a change is needed. In the Everest example, analysis led to checking phone numbers on the form. The action followed from finding both the fault and the opportunity to correct it.
End
For the work of changing processing requirements into Engine rules, see the Engine configuration page.
Work from the information the programme holds
Capture and processing records describe what happened within the programme. Later conversion outcomes depend on information returned from connected systems. The review needs to distinguish those sources and make clear which part of the record’s journey each one describes.
Frequently asked questions
Do we need to return sales outcomes to investigate capture quality?
Capture-quality analysis can use the records and check results at the point of entry, as the Everest example shows. Investigating later conversion needs information about the later outcomes being examined.
Does a failed check mean the source supplied a bad lead?
A failed check means the record did not meet a particular requirement. The requirement and the failure need examining before deciding what that says about the source.
Does a record passing the checks mean it should convert?
Passing establishes that the record met the programme’s specified checks. Conversion is a later outcome. The page on getting sales to accept your leads examines why sales may reject a record even when it passed those checks.
Explore related pages
- Technical data services— how the technical team connects your systems to the Engine.
- Engine configuration— how requirements become processing rules.
- Lead validation— the four checks and how the order of processing is set.
- Getting sales to accept your leads— why sales may reject records that passed our checks.
Bring the result you cannot explain
Tell us where your team is seeing a problem and what information you have about the affected records. We can discuss the question the analysis needs to answer.