Social Proofing
Updated over a week ago

What is Social Proofing in Webtrends Optimize?

Social proofing is our ability to return real-time, aggregated user activity back to the browser.

For example – “tell me how many people viewed products 000001, 000002 and 000003 in the last day“.

If unfamiliar with the concept, please see our articles on what it is, and what you should think about when undertaking the project.

Here, we address the practicalities of interacting with the API.

Storing behavioural data

Firstly, we must store all of the behaviour you’d like to aggregate. You can interact with our API to send details in the following format:

POST https://<host>/<your_id>-store
{
"event": "<event_name>",
"pid": "<product_or_content_id>"
}

For example

POST https://somewhere.azurewebsites.net/webtrendsoptimize-store
{
"event": "view",
"pid": "help_devdocs_socialproofing"
}

The API should respond with "N records inserted" if successful.

Note: Wherever possible, we use anonymised domain names such as azurewebsites.com for our services. This will happen more over time. These anonymised domains are less likely to be subject to adblockers and third-party domain browser restrictions.

Suggested approach – Beacon API

We always suggest using the Beacon API where it’s available. This is more resilient, and has greater security than making POST requests from the browser.


Sample code to do this is as follows:

var sendSP = function(o){
var url = "https://somewhere.azurewebsites.net/api/webtrendsoptimize-store";
o = JSON.stringify(o);

if(window.navigator && navigator.sendBeacon){
navigator.sendBeacon(url, o);
} else {
var xmlhttp = new XMLHttpRequest(); // new HttpRequest instance
xmlhttp.open("POST", url);
xmlhttp.setRequestHeader("Content-Type", "application/json;charset=UTF-8");
xmlhttp.send(o);

}
};

You can then simply pass all of your behavioural data to this function:

sendSP({
"event": "view",
"pid": some_variable_for_product_id
});

Different expiry per type

If you wish, you can set records to expire at varying times – just include a ttl attribute with a time (seconds) for expiry.

Example: “I want to Views for 30 mins, Views for 6 hours and Purchases for 1 day”.

For the views, you could send us:

[{
"event": "view_30m",
"pid": "help_devdocs_socialproofing",
"ttl": 1800
},
{
"event": "view_6h",
"pid": "help_devdocs_socialproofing",
"ttl": 21600
}]

This will save two records for views. You can then query back with event=view_6h for just the 6-hour data.

Reading behavioural data

There are 3 configurable aspects to what data you can retrieve from our Social Proofing engine:

  • Time (rolling window): How long you want your records to survive for in our database. Known as TTL (Time to live).

  • Event: Which event/s you want to query.

  • Product ID: Which products do you want to query.

Time (rolling window)

We configure this once, for your account, on the database-side. Please let us know what timeframe works for you – we default to 48 hours
We are currently unable to allow users to query by time window flexibly through the API, but can facilitate custom requirements on request.

Event

Whichever events you provide to us become immediately indexed, and available to query in real-time (typically sub-second).
You must provide at least one event to the API, but can provide multiple events as comma-separated values.

Product ID

This behaves exactly like Event – all data provided to us is immediately indexed, and can be retrieved as one-or-many in a comma-separated list.

Sample call

GET https://<host>/<your_id>-read?event=<event_list>&pid=<product_id_list>

For example:

GET https://somewhere.azurewebsites.net/webtrendsoptimize-read?event=view&pid=WT0001,WT0002,WT0003,WT0004,WT0005

If successful, the API should respond with an Array of JSON objects, containing the attributes event, pid, total.

[{
"event": "view",
"pid": "WT0001",
"total": 300,
},
{
"event": "view",
"pid": "WT0002",
"total": 1,
},
{
"event": "view",
"pid": "WT0003",
"total": 10000,
},
...
]

You may also want to only include data where totals are above a set figure e.g. 100 or higher – this should be filtered-out on your application-end.

With this data, you can then build your onsite experiences using your own themes and designs.

Did this answer your question?