Using PingTree.aspx

TSL Ping Tree > Page Usage

Using PingTree.aspx

The core functionality of TSL Ping Tree is to validate, filter, and distribute real-time online leads in response to web form submissions.  The possible destinations ("Lead Points"), their filters, their distribution rules, etc. are collectively what we call a “Ping Tree”.

Configuration tab

Configuration Item Description
Name A unique Ping Tree name up to 255 characters.
Ping Tree ID A unique Ping Tree ID up to 36 characters. The ID can be anything but if left blank then the system will find the next available "number", e.g. "1002" will follow "1001".
Unique Lead Duration This feature is here to improve conversions when the source of your live leads has not been hardened to prohibit submit button double clicks and back button retries while your ping tree runs.

Each time a ping tree executes it blocks the same lead from being able to run the ping tree at the same time for some small duration of time.  The definition of "same lead" is based on the ordered list of items that you define in your Ping Tree configuration.

The default duration is 1 hour and the default pattern is "ClickId|PingTreeId" e.g. "1326105|1001".

Details:

As ping tree execution starts for a given lead the system creates a lock against that lead per the duration and pattern you set.  As ping tree execution completes the lock is released and the number of accepts and its first redirect URL are recorded.  Once a lead reaches the maximum number of accepts for a given ping tree then that lead will not be permitted to run the ping tree again for the duration set for this unique lead feature.  Any attempt to run the ping tree again under this condition will result in a reproduction of the previous accept result including the redirect URL from the first accept, if any.  Note that if submits of the lead within the set duration result in less than the maximum allowed number of accepts then the ping tree will be allowed to run again; Duplicate Rules should be in place to prevent this action from bothering your lead buyers.

This feature is extremely important for your conversions.  Consider a ping tree that permits only one quota-counting accept per lead.  If a submit results in a quota-counting accept then the party that accepted the lead is expecting to own that lead and probably expecting to receive a redirect from the visitor.  However if the visitor hits the back button and resubmits the page before the result can be returned from the first submit then the ping tree will be asked to run again.  This unique lead feature ensures that the ping tree will not run more than once at a time for the same lead and that once the quota has been reached then the first redirect URL produced will be the one that is returned.  So the visitor who hit the back button and resubmitted will receive an accept with the first redirect URL and will be redirected to the original buyer.  No other buyers would have been tried.

This feature is not used very often for a Headless Site (i.e. when you or your affiliates post leads to submit.ashx on a one-Click to one-Submit ratio basis) however it could be used there especially if the affiliate is posting directly from a website to you and only you versus posting to you from server-side code.  For a Front Site (i.e. a website that you or your affiliates host where a session takes place, possible multiple ping trees can be run during the session, and ping trees can be retried on errors) then that is where this unique lead feature is essential especially for verticals such as payday loans where getting the consumer over to an electronic signature page for follow up action is critical for producing a valid lead.  Consider a consumer who does not like the result of your first ping tree run and who hits the back button, tweaks some nonessential data on the form, and resubmits to run the ping tree.  Without this safeguard the lead may be sold again elsewhere in your ping tree.  Now you have two potentially unhappy lead buyers because the first one will never be reached again and whether this type of consumer fills out the e-sig page for the second remains to be seen.  So the unique lead feature works to keep the consumer tied for some small period of time to the initial accept results obtained.
Unique Lead Pattern
Form Select a Form for this ping tree.
Maximum Accepts Per Lead Enter 1 for an exclusive lead, e.g.  For semi-exclusive enter a number greater than 1.
Max Runtime Seconds Optionally enter the maximum number of seconds that the ping tree will be allowed to run. The remaining time is checked before each lead point is run to see if there is time left. If not, then the ping tree times out. If so, even if there is only 1 second left then the next lead point will run with the timeout of the lead point, not just the remaining 1 second for the ping tree.
Require SSL When checked then any form submission received for this ping tree will be immediately rejected if it is not done over SSL.  We strongly recommend the use of SSL.
Ignore Query String When checked then the system ignores all parameters supplied in the URL via e.g. "?firstname=Fred&lastname=Flintstone" or otherwise supplied via the HTTP GET method; only parameters supplied via the HTTP POST method will be processed.  We recommend this setting because it has less of a chance of leaving consumer data in browser, web server, and proxy server logs, e.g.
Tie Goes To: First Vs. Last If a parameter is specified twice in the HTTP GET data, or twice in the HTTP POST data, then this setting determines whether it is the first or the last occurrence that the system will accept.  Note that if a parameter is supplied once in the HTTP GET data and once in the HTTP POST data that this setting has no affect.  Use the next Tie Goes To setting for that situation.
Tie Goes To: Get Vs. Post If Ignore Query String is not checked and a parameter is supplied in both the HTTP GET data and in the HTTP POST data then this setting determines which one the system will accept.
Require Existing Click ID When checked then a submit will be rejected unless it is accompanied by a Click ID via either the "c" Click ID system parameter or via a tracking cookie made by the system's ClickThru.ashx handler.  This is a good feature to use on a Front Site to safeguard against affiliate lead fraud, e.g.
Respond With: XML Vs. Redirect The system has two modes of operation when it comes to responses.  It can either respond with an XML document that describes the outcome of running the ping tree or it can issue an HTTP 302 Redirect to an Accept, Decline, or Error page.
Accept Redirect URL This is an optional default URL to use if the ping tree results in an Accept and no redirect URL was returned from any of the accepting Lead Points.
Decline Redirect URL This is an optional URL to use if the ping tree results in a Decline. This feature is now available for both Redirect and XML responses.
Error Redirect URL This is an optional URL to use if the ping tree results in an Error and the ping tree is configured to respond with Redirect (vs. XML).  Note that if the ping tree is configured to respond with Redirect and an Error results with no URL defined here then a very simple system-generated error page will result.  That page will list all of the errors and instruct the user to hit the back button to correct the errors.  We do not recommend this for the long run but when getting a new offer website off the ground it is an OK shortcut just to see if the site is on its way to converting well without putting in a bunch of effort on pretty error handling.
Error List Type This is only applicable when the ping tree is configured to respond with Redirect (vs. XML).

When set to None then no errors will be returned.

When set to HTML List Items then the format of the error parameter's value will be <"LI>message</LI>" or "<LI title='fieldname'>message</LI>" for each error.  Whether fieldname is included depends on whether On Error Post Form Fields is checked.

When set to Tab Delimited then the format of the error parameter's value will be "fieldname=message" or just "message" delimited by the tab character (ASCII 9).  Whether fieldname is included depends on whether On Error Post Form Fields is checked.

NOTE:  For all list types other than None the set of errors will be DOUBLY URL ENCRYPTED so URL decode logic must be used TWICE to decode them.  This was done to get around form scripting attack safeguards on web servers where that behavior could not be selectively turned off by our customers.  So for example if two errors are produced regarding two different required fields and the format is Tab Delimited then this...
  • Field 1 is required.
  • Field 2 is required.

... will become the value "Field%25201%2520is%2520required.%2509Field%25202%2520is%2520required.".

URL decode this example once to get:  "Field%201%20is%20required.%09Field%202%20is%20required."

URL decode a second time to get:  "Field 1 is required.»Field 2 is required."   (The » symbol denotes a Tab in this example.)

On Error Post Form Fields For Redirect (vs. XML) responses only when "Error List Type" is not "None", if this checkbox is checked then the names of the form fields will be returned for each form field based error; if unchecked then only the error messages will be returned.
Error List Parameter For Redirect (vs. XML) responses only when "Error List Type" is not "None", the name of the HTTP parameter to use when encoding errors within the Error Redirect URL, e.g. "err" will produce something like "https://mydomain.com/mypage.php?err=Promotion%2520ID%2520is%2520required"
Daily Limit Timezone Select a time zone if you wish to put daily accept or submits on this Ping Tree.  The selected value does not mater if no limits are specified.
Daily Limit For Accepts An optional limit on how many accepts can be produced per day.
Daily Limit For Submits An optional limit on how many submits can be received per day.
Filters Optionally add Ping Tree level Filters here.
Notes Anything goes here.
Enabled Uncheck to disable this Ping Tree.  Submits to a disabled Ping Tree will produce an error.
 

Ping Tree Order tab

Right click on the ROOT, any Tier, or any Lead Point for a context menu to add or delete.

Left click on a Tier or a Lead Point to edit it.

Left click and drag to move a Tier or Lead Point.  Dragged item will be moved immediately after node on which it is dropped.

 

Tier Configuration Items

Configuration Item Description
Name A unique name for the Tier up to 255 character, e.g. "Top Tier".
Mode Ordered will run all of the Lead Points in the Tier in the order that they are listed.

Weighted will choose a random number biased by the relative weight of each Lead Point in the Tier.  Weights are defined for each Lead Point in each Lead Point level node of the Ping Tree.
Round Robin Chooses the next lead point in sequence based on the previous ping tree runs. Note that the Tier Name is one of the keys used to determine which lead point position will be selected next, so if you change the tier name, the round robin will start over at the first lead point position.
Run which Leadpoints Only applies to the Weighted mode.  Weighted mode can pick just one Lead Point from the Tier and then move on to the next Tier or it can exhaust all Lead Points before moving on to the next Tier.
Maximum Seconds Enter an optional number of seconds to permit this Tier to execute.
Exit Tier on Max Accepts If this is checked and you reach the sale count limit on the ping tree no additional lead points will run in this tier even if a tier does not count toward quota.
Enabled Uncheck to disable the entire Tier.
Attached Filters You can attach filters to the tier using this control. Typically, you should only use Decline filters, NOT Error filters. If you use Error filters and the lead is ultimately not sold, the field errors will propagate back to the response.
 

Lead Point Configuration Items

Configuration Item Description
Lead Point Select a Lead Point to include in this Tier of this Ping Tree. Lead Points can be used across multiple Ping Trees.
Minimum Receivable Amount Only available on dynamic priced leads points. This is the minimum acceptable price for this lead point position. If the dynamic reported price falls below this value, then the sale is accepted, but the lead point position is disabled.
Treat Missing Price as Zero Only available on dynamic priced leads points. If this is checked and the response does not contain a price, then the price is treated as 0.00. If that is below the minimum receivable amount (described above), then the lead point position is disabled.
Weight Only applies to the Weighted mode.  This is the relative weight of this Lead Point over the others in this Tier.  For example with three Lead Points weighted 2, 1, and 1, respectively, then the first Lead Point has twice as much of a chance of being picked as the other two.  More precisely, the first one has a 50% chance and the other two each have a 25% chance.  This could also have been expressed via weights 50, 25, and 25 or 0.5, .25, and .25.  It does not matter as the math is done correctly regardless.
Timeout Seconds Enter an optional number of seconds to wait for this Lead Point to answer.  Does not apply to Lead Points with a Response Type of None.  Note that this value may be posted to a Lead Point in its Interface via Lead Point Item "Allowed Response Time" i.e. "${lpi.Allowed Response Time}".
Timeout Grace Milliseconds Enter an optional additional number of milliseconds to wait for this Lead Point to answer in addition to the publishable Timeout Seconds value.  Use this to grant a grace time period for network lag, e.g., without publishing to the Lead Point that this is part of the amount of time that you are expecting to wait for a reply.
Abort Tier If Not Accepted Check to cause the Tier to be aborted if this Lead Point does not accept.  This can be used for many reasons.  For example, to implement a "ping/post" set up a Tier to be an Ordered tier with two Lead Points.  Its first Lead Point is the "ping" to your buyer.  Its second Lead Point is the "post".  Set the first Lead Point up in the Tier to Abort Tier if Not Accepted.
Abort Ping Tree If Not Accepted Check to cause the entire ping tree to abort if this Lead Point does not accept.  This is usually done when this Lead Point is some sort of thurd party quality validation service and the entire Ping Tree is full of buyers that expect premium quality leads.
Count Accepts Towards Quota When checked then accepts by this Lead Point count towards the maximum number of accepts allowed for this Ping Tree.  Uncheck when copying leads to an in-house CRM, a third party data quality service, a List Management company, etc.
Enabled Uncheck to disable this Lead Point in the given Tier.