When leads are delivered via HTTP, the recipient server provides a real-time response. LeadConduit Classic must interpret this response to determine the outcome of the delivery. In LeadConduit Classic, this is done by parsing the server response using regular expressions. Response Parsing is critical to determine the final outcome of your lead delivery to a destination and in troubleshooting delivery errors. Since knowledge of regular expressions is required to properly configure response parsing, it is best suited to a technical person.
Valid response pattern
The first check for every response is whether or not it is valid. In other words, were we able to properly communicate with the server? At this stage we aren't concerned with whether the lead was good or bad - just with whether or not it was received by the recipient server. If the response matches the pattern for valid response, LeadConduit Classic will continue evaluating it (see below). Otherwise, the delivery is treated as an error and LeadConduit Classic will continue trying to deliver the lead, until a valid response is received. During this time, the lead will be in PENDING state.
This pattern must include exactly one regular expression "match group". This is a sub-part of the regular expression, denoted by a pair of parentheses, which will be used in the later phases of response handling.
(.*) is a regular expression that would match ANY result from the server - meaning that the lead request did reach the server and signifying a valid response.
Error response behavior
If LeadConduit Classic doesn't receive a valid response it considers it an error. LeadConduit automatically tries to resend the lead if an error response is encountered. It will retry once a minute for 7 days. During this time, the lead will be in a pending status. If you have a situation where a recipient server is receiving the same lead over and over, it is probably because we are interpreting their server response as an error.
Success response pattern
Once a response is known to be valid, it can be further evaluated to see if the delivered lead was accepted or rejected. The pattern for success responses is used to see if the lead was accepted by the recipient. Any response that doesn't match this pattern will be interpreted as a failure. (There is no way to define the pattern for a failure response; it is simply any valid response that is not a success.)
The success response is compared to the contents of the "match group" from the pattern for valid response (see above).
For example, suppose you set the pattern for valid response to:
.*<status>(.*)</status>.*. In this case, the pattern for a success response should be the success value that comes in the
accepted. In this example, a response that contains
rejected would be treated as a failure.
Some buyers prefer to indicate acceptance by responding with a 200 OK response code without a response body. When a buyer uses this method to accept leads, the vendor need only parse for a valid response from the server and utilize a regular expression ("^(?![\s\S])") to check for an empty response body.
When a reject response is received, the pattern for reject reasons can be used to capture the reason(s) why the lead was rejected. This setting is not required, but your Bad Lead Report will include these reasons, if they're available. Of course, this does not apply to success responses.
The text available to search for reject reasons is the contents of the match group defined above in the valid response pattern. Within that match group, this reject reason pattern defines which part contains the reason why the lead was rejected (e.g.,
Zip code not serviced).
This pattern must itself include at least one match group. Each group matched in a reject response is saved as a a reason why the lead was rejected. Multiple reason-matching groups are permitted.
Response Handling Example
For example, the following is a fairly standard response pattern setup:
Pattern for valid response:
Pattern for ACCEPT response:
Pattern for reject reasons:
The valid response pattern ensures that the response begins and ends with the XML tags
</response>. If the response doesn't match this pattern, the response is considered an error, and LeadConduit Classic will continue to try re-delivering the lead, as configured. If the response does match, then the
(.*) match group makes everything in between the tags available for later evaluation.
If the text between the
<response> tag is exactly equal to
<staus>accepted</status>, then the lead will be marked accepted, and that delivery is finished. If that text is anything else, then the lead will be marked as a failure, and the 3rd pattern will be applied.
(.*) in the reject reason pattern defines a new match group which is applied to the same text that comes out of the valid response evaluation from before, If that text has the tags
</reason> anywhere within it, then everything between them is saved as the reject reason for this lead. Note that including
.* before and after the reject reason pattern allows it to match even if there is other text before or after the tag. That is, there may be other text inside the
<response> tag besides the
<reason> tag, but it will be ignored.
Given the configuration above, here is how various responses would be evaluated:
Result with Sample Configuration
|lead marked success|
|lead marked failure, but no reason recorded (leads like this
will show up as "unknown reason" on the Bad Lead Summary report)
|lead marked failure with reject reason of "duplicate address"|
|lead marked failure with reject reason of "duplicate address"
This is the same as the previous example, but with additional tags in the response. Due to the leading and trailing ".*" in the reject reason pattern, however, the extra information is ignored.
|lead marked failure. The extra data before and after the <status>
tag (<date-time> and <server-rev>) are not allowed with the given
accept response pattern. If that pattern were changed to
".*<status>accepted</status>.*", then this lead would be marked accepted.
|<error>Databaseunavailable</error>||delivery error; LeadConduit Classic will continue trying to deliver|
The best way to check to see if you have properly configured response parsing is to test it by submitting a lead. In LeadConduit Classic, the server response from each delivery destination is captured with the lead as part of the "Delivery Summary." Simply compare the captured response with LeadConduit's interpretation of that response to make sure they are consistent.
We often get support inquiries asking: "Why does LeadConduit Classic consider this lead good when it was rejected by the recipient's server?". This usually means the response parsing was not configured properly.