What is a Delivery?

A Delivery is how leads are individually sent from your LeadByte Campaign to another party. This other party may be a Buyers remote system, your dialler or even another LeadByte campaign within your own account. Using the options described below you are able to fine tune which leads go to which Delivery and how/where they are sent.

Manage Deliveries
 

Under the Manage Deliveries tab you are given an overview of all Active, Inactive and Saved Deliveries. A Delivery will remain under the saved tab until you have successfully tested it. Once this has been completed, it will move from Saved to Inactive where you can enable it when ready.  

Add New Delivery/Edit Delivery

Delivery Name*
This is what your delivery will be called on reports or when searching the system

Trigger Type*

• When lead arrives (automatic)

Deliver a lead when it enters your campaign and matches the criteria / rules of the delivery.

• Manually / via code

To trigger a Lead via the REST API, you will need to generate an API key which you can do under ADMIN>REST API. On this page, you will be given implementation notes to get you up and running. Each Delivery has it's own Delivery ID, which is used to trigger your Lead forwarding. More on this can be found here.

If you want to trigger a delivery off another delivery, the delivery you want to trigger must be set as Trigger Type: Manually - after doing so, the manual delivery will appear in the dropdown when configuring a delivery with "On Success, trigger delivery"

Campaign*
Select the campaign that you want to link this delivery to. You can link multiple deliveries to a campaign.

Method*
This is the method for delivering the lead.  Your options are:

• 2 Step Authentication

If your clients remote system needs you to make an authentication call to gather a token before submitting the lead data, you will need to use this method. This is useful when you need to perform two calls in one delivery while extracting a token from the first call response, so you can use that token in the header for the second call.

• Campaign Transfer

Transfer a lead to one of your other LeadByte Campaigns.

• Direct Post

This could be a CRM, Dialler, ESP to name a few. This is the most commonly used Method.

• Email

Send leads to a given email address as soon as they arrive.

• PingPost

Enables you to Ping your Buyers API with partial lead data and based on the response, create rules on whether or not you wish to Post the full lead data to your Buyer. Similar to 2 Step Authentication, the main difference is that with PingPost, instead of extracting a token to use in a header - you can extract multiple parts of the response to put into your second calls payload body.

• Store Lead

Use this option if you only want to assign a lead to a buyer. This can be based on rules e.g. must be 18+ and live in a specific postcode area.

• SMS

Send lead information directly to a given mobile number.

CRM/Type*
After selecting "Direct Post" as your method - you will see a dropdown for CRM/Type. This lets you specify which type of direct post action you want to use to deliver your leads. The most commonly used are:

• HTTP JSON

To send leads via the POST method, using a JSON payload.

• HTTP POST

To send leads via the POST method, using a form payload.

• HTTP GET

To send leads via the GET method

URL*
Enter in the endpoint URL that you are posting the lead to.

Advanced Distribution only

By ticking this option, the created Delivery will only run if it is part of an Advanced Distribution setup within the selected Campaign. This can be managed under Campaigns>Settings>Advanced Distribution. 

This will enable you to set the Delivery to active without worrying about leads being Delivered until you add it to your Advanced Distribution schedule.

When a delivery is toggled off in the advanced distribution, this means the delivery will run on standard distribution which runs alongside the advanced. This can result in multi-selling as the standard deliveries will always run (if the rules allow it) - ticking advanced distribution only will prevent deliveries from running in the standard distribution when toggled off, allowing you to safely leave the deliveries toggled off in the advanced distribution with accidentally multi-selling leads.

More on Advanced Distribution here.

Deduplication

Delivery deduplication allows you to set up deduplication that will only run on a single delivery. 

Delivery deduplication works the same as the "Advanced Campaign Deduplication" - meaning that if you have both email / phone1 selected in the dropdown, both fields will need to be identical to another lead at the same time to skip this delivery. This article goes over Deduplication on Delivery

This deduplication is independent from other deduplication types and will only start detecting duplicates starting from when you tick the box and save the delivery. If a lead comes in before you enable it and a duplicate comes in afterwards, it will not skip the lead until it comes in the second time following delivery deduplication activation.

Buyers & Financials 
If you are delivering leads to a Buyer (client) you will need to select the Buyer here.  This is important if you want to track which buyer the lead has been assigned to and the revenue.  You have three options for associating Revenue

Revenue type:

Fixed
This is the most common.  The revenue amount will be assigned when the delivery is successfully triggered.  If the lead is being delivered to a remote system, it will be when the remote system responds with the success code that has been configured in the remote system response section.

Dynamic
This would only be used when delivering to a remote system.  If your Buyer will respond with a revenue value, this can be captured and stored. 

This article goes over Dynamic revenue type in more detail.

Rule based
IF you want to associate revenue against a lead based on specific data, this option would be used.  For example, you may get paid 10.00 if the lead is Female and 5.00 if the lead is male (defined off the Gender field).

In the below example, the Buyer will pay £15.00 for leads that have "Facebook" as a Source. If the Source does not match this value, the fallback amount the Buyer will pay for the lead will be £10.00.

Rule Based revenue is also one of the places you can set up varying supplier payout amounts, based on field data. Typically the payout is configured in the campaign configuration - either by setting the default amount for all suppliers or setting individual custom payouts for specific suppliers. With rule based revenue, you can configure different deliveries to payout different amounts to suppliers by changing the value in the payout box.

Caps 
Use caps if you want to restrict the number of leads that should be delivered.  For example, you may have an agreement with your Buyer that they only want 5 p/day with a total order value of 100.  You would enter 100 in the Total caps box and 5 in the Daily caps box.  For further info on Delivery Caps please click here.

In the caps section there is a "Default cap type" setting which has "Delivery" & "Buyer" as the choices.

If Delivery is selected, the caps that are configured directly beneath will be used for this delivery.

If Buyer is selected, the delivery caps will be completely ignored and the delivery will instead run off Buyer caps that are configured inside each individual buyer's user settings. Whenever you want to use Buyer caps, you must ensure that you set this setting to Buyer, or your buyer caps will not work.

Custom Data Mappings
When using the HTTP POST CRM/Type (or other methods such as "Email") - you will see a section called Custom Data Mappings. This is a friendly UI that will allow you to configure which lead fields you want to send over in the delivery.
 

Add New Mapping
This will enable you to add a new mapping.

Input Field
This is your campaign field you want to deliver.

Output Field
This is the name of the field you want to deliver to the client, the label that your input field will be renamed to.

Static Value
Anything which is in this field will be posted out with each delivery. For example, it may be a password/key or an additional field that you do not collect on the campaign such as a broker code that the remote system has assigned to you. This does not need to be filled unless you want to send over a static value every time.

Sample Value
Sample values are used for testing purposes. Standard fields are populated for you however, you will need to enter in sample values for any additional fields or field mappings you create

Options
Advanced options for each mapping. Here you can translate values, set a format (eg DD/MM/YYYY needs to be posted out as YYYY-MM-DD) or make Last Name UPPERCASE.  Further example here.

Custom Post Data

When configuring a CRM/Type such as HTTP JSON (the most commonly used direct post type) you will see a payload box titled "Custom Post Data" - this is where you will construct your JSON payload.

You can insert LeadByte tags by selecting the area you want to insert the tag, clicking "Show tag help" and then selecting the tag you need such as [firstname].

To enter a static value instead of a tag, simply type the static value into the key value instead of the tag.

After you are done creating your payload, ensure you click the "Validate JSON" button to see if the structure is valid. Typically an invalid payload will be because of missing quotations or incorrectly placed commas.

The Sample values section works similar to the "Custom data mappings" mentioned above. The sample values put into the box will be the values that are sent out when performing a test at the bottom of the delivery. The "Options" button next to each field will allow you to set the output format, as well as allowing you to translate values.

Schedule

You can set up a schedule on your delivery to dictate when you would like this delivery to be active. When a lead comes in outside of the scheduled time, the delivery will be skipped and the lead will go to a different delivery instead. You can use the Lead Quarantine to quarantine leads that have been skipped and then release them when your delivery schedule is active. The timezone used for the schedule will be the same as your account timezone - however, selecting a different timezone in the dropdown will run the schedule off the selected timezone instead.

Location Filtering
States/Regions can be selected, filtering further with counties if needed - this works off the Zip/Postcode field in the lead data and will skip delivery for any leads that don't match the selected location/s, based off the Zip/Postcode. This is only available for certain countries. More reading can be found here - Location Filtering on a Delivery

This feature works independently to the general delivery rules.
 

Rules
Rule determine if a delivery should be triggered.  For example, if your Buyer only wants leads within a specific postcode / zipcode range you would create a rule for this.  You can read more about rules here.  With Rules, you can save them as a template which means you can use them in other deliveries to save you time.  Many of our clients have complex rules, so saving rules as a template can be a big time saver.

Remote System Response
Here you should enter the responses from the remote system (both success and reject messages). These responses can be taken from an integration guide you receive from your remote system. In some cases a remote system will send back multiple success codes. 

The most common configuration for Remote System Response would be:

• Click +Add Response Row
• Select Match by HTTP Status
• Select 200 OK as the HTTP Status
• Set the label as Success (or whatever you want)

This will result in any time you send a lead to the delivery and it responds with a HTTP 200, it will mark the lead as successful.

Please note that some endpoints may respond with HTTP 200 even when a lead has not been successful. If that is the case then the second most common option would be:

• Click +Add Response Row
• Select Match by Keyword
• Enter a specific keyword that the endpoint response will contain to signify that the lead has been successfully submitted (for example, LeadByte sends back the keyword "Approved" when a lead is successfully sold, when using Live Buyer Responses)
• Set the label as Success (or whatever you want)

If you want to map a portion of the response to a lead field, you can do so by clicking Edit. More on this here - Assign delivery response to a lead field

TIP - be sure that if you use keyword that the word used in a success response code is not used in an unsuccessful response code (it happens a lot)

 

Trigger SMS/Email when Delivery successful
Let's say you deliver HIGH VALUE leads to your Buyer's CRM but they want to be sure that they are "on it".  You have the option to send an email and/OR SMS when the lead has been successfully delivered.  See image below.  Remember, this is a billable service.
 

On Success, Trigger Delivery 

Let's say you want to document all of the leads that are sold to your own CRM/BI for reporting purposes. This is a handy tool where you can trigger another Delivery to send the lead information to another endpoint if the parent Delivery is successful. Please note that you can only trigger REST API Deliveries. (Trigger Type will need to be set to Manually/ via code).

On Failure, Trigger Delivery

Let's say you want to do the same as the above, but only want to document leads that are unsold. This option will trigger another Delivery to send the lead information to another endpoint if the parent Delivery has failed. Please note that you can only trigger REST API Deliveries. (Trigger Type will need to be set to Manually/ via code).

Advanced Settings
Some remote systems require certain fields to be posted out in the header of a message. The screenshot below shows an example where the remote system needing an API key to be posted in the header.

 

SSL cipher list
A cipher code may be required if the remote system you are posting to uses cipher suites as a security protocol on their network.   When testing, you would likely see the error message "Cannot communicate securely with peer: no common encryption algorithm(s)" if cipher suite is installed and you have not entered in the value.  The client should provide this.  You can use this site to see if the system you are posting to uses Cipher suite: https://www.ssllabs.com/ssltest/ and obtain the cipher suite being used.  From this, you can obtain the cipher value on this site: https://unix.stackexchange.com/questions/208437/how-to-convert-ssl-ciphers-to-curl-format
 

The remainder of the settings are for advanced users but feel free to reach out to us if you have any questions

Test Delivery
In order to set move a delivery from Saved to Inactive you'll need to send a test delivery to make sure it's working. This prevents you from enabling a delivery which doesn't work! The test lead sent contains the sample values from the mappings section detailed above

Using TAGS
This is relevant if your delivery is Email or SMS (including sending an email/SMS on successful delivery to a remote system).  See the image below, It illustrates how to customise an email delivery using tags.

 

Useful Tags
 

• [received] - outputs the received date/time of the lead
• [deliveredtime] - outputs the date/time the lead was delivered
• [age] - outputs the age of the lead based on the DOB collected
• [dobday] - works off the DOB value, outputs just the day
• [dobmonth] - works off the DOB value, outputs just the month
• [dobyear] - works off the DOB value, outputs just the year