||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".
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
||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.
||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.
||Optionally add Ping Tree level Filters here.
||Anything goes here.
||Uncheck to disable this Ping Tree. Submits to a disabled Ping Tree will produce an error.