Getting a dynamic value from your website
There are times when you may wish to include dynamic content that your website recognises into Bunting actions. Examples include time-sensitive discount codes, unique for every visitor, within banners, lightboxes and cart abandonment emails. To do that you can insert GET calls.
GET call syntax
The syntax you enter into an action, to perform a GET call to your server, is as follows:
*|GET|web address|alternate content|cache expiry|*
The first parameter – web address – is mandatory. This is the address of a script, typically located on your website, that will generate a value such as a discount code, save it to your website’s database, and output that value via HTTP for Bunting to collect. The output from your website must be isolated purely to the value you want Bunting to give to your visitors. Do not include HTML of any kind, unless this too is intended for your customers. If the value is sensitive (such as a money-off discount code) then we recommend you protect the page by including a query string such as ‘password’ for your system to validate. For example:
The second parameter – alternate content – is optional. This is alternative content that will appear to your customers should your server be unreachable. In the latter example you may want to enter a generic discount code, so that if your server cannot be reached to provide the customer with a unique discount code, then that generic discount code will instead be provided. If your server cannot be reached and you choose not to include any alternate content then the GET call code will simply be removed, and your customers will see nothing.
The third parameter – cache expiry – is also optional. When a GET call is performed the value returned from your script (located at the web address you entered) is cached within Bunting. This markedly improves loading speeds for your customers’ benefits, and reduces processing on your server. During the cache lifespan your server is not called and the cached value is used instead. Expiry of a GET call cache doesn’t mean that the value will no longer be displayed to the visitor, it simply means that Bunting will again contact your server for the value (a slower process), then re-cache the result. In 90% of cases you won’t need to pass a value for this third parameter. If you don’t then the cache lifespan is set as the default 30 days, unless the GET call is inserted into an action that also contains a countdown timer, in which case the cache expiry will automatically be set to coincide with the expiry of the timer. Although it’s unlikely you’ll need to, you can override the default cache expiry behaviour by entering your own expiry period value as the third cache expiry parameter:
1) A numerical value between 1 and 8765 represents the expiry in hours from the time the GET call is first performed. 8765 is the number of hours in one year, thus one year is the maximum of this type. This expiry starts relative to when each visitor sees it. If visitor A first sees the GET call 10 minutes before visitor B, then their cache will also expire 10 minutes earlier.
2) A Unix Timestamp; a 10-digit number that can be used to identify any time to a precise second. Say you wanted all GET call cached values to expire at a specific date and time (such as mid-night on New Year’s Eve) you would use a timestamp. This website will let you easily create a timestamp to your needs.
3) The word ‘Midnight’ means the cache will expire at midnight of the day it is called.
Important syntax notes: All three parameters must be separated by|pipe|symbols|. The word GET must be in capital letters. If a second and/or third parameters are added then the two or three parameters must be separated by commas with no spaces. All three parameters must be surrounded by brackets.
Returned values can only be 250 characters, or less. Values generated by your server greater than 250 characters in length (including any HTML characters) will be cropped to just 250 characters.
You can only include one GET call per Bunting action.
Say you wanted to add a unique discount code for each visitor, with a fallback value of ‘10-OFF‘ should your server not respond, your GET call may look something like this:
For the same call, without a fallback value, your GET call may look something like:
For the first call, with a cache lifespan of 4 hours (meaning, your server is not called for another 4 hours from the time the first GET call is performed per visitor, your GET call may look something like:
The visitor_id and action_id URL Parameters
For every web address you enter in a GET call, Bunting appends two URL parameters of ‘visitor_id‘ and ‘action_id‘. The visitor_id parameter contains the ID number of the profile in Bunting that is associated with the visitor who has triggered the GET call. For example, the command:
would actually call the following address on your server:
when the parent action is triggered by a visitor to which Bunting has assigned ID number ‘12345’
Whereas with a visitor with the ID number ‘456’ :
The action_id parameter is the numerical reference of the action in Bunting that is calling your server (such as a lightbox, a header bar, an email, etc).
Your website’s response script could ignore both these values, or optionally choose to use and save them in order to remember which values it has already generated and for who. You could, for example, use the values to ensure uniform behavior; so that every visitor only receives the same code that is unique to them, rather than being given a new code every time they trigger the action containing the GET call. This, however, isn’t relevant if the third cache expiry parameter is set to cover the lifespan of the discount code.
Cache values relative to visitors
Cached CALL values are made uniquely for every visitor who triggers an action containing a GET call. For example; two GET calls made within the cache lifespan for two visitors, will call your server twice and cache both those values. On the other hand, three calls made within the cache lifespan for just two visitors will call your server only twice, caching both values, and recalling a previously cached value once.