If you want to merge data from different ads then it is possible to do, however we strongly advise that this is only done if your data merge meets any one of the scenarios below:

• You have run two or more separate facial coding tests using the exact same media file in both instances
• You have run two or more separate facial coding tests using very similar ads with only minor differences, such as a different language overlaid across the same video. 
• You have run two or more separate facial coding tests using similar ads that have a few seconds of different content, but are otherwise the same. 

In all above cases, the ads must be practically identical in length to ensure the data remains meaningful post-merging. If one ad is a few seconds longer than the other then this can give false impressions of the audience response towards the end of the ad as suddenly the sample is reduced by 50% for X seconds, where X equals the difference in length between the two ads. 

There are four methods for merging the data: 

Grouping ads into a single study

Use Case: You have tested two or more media which you wish to compare and contrast on the same study page.

Summary: This method isn't a true merging of data; rather it allows you to view the results of multiple ads along side each other. So rather than having two separate studies, each with their own charts, you can instead have a single study that depicts the trend lines for both ads on the same chart, allowing for ease of comparison. 

Procedure: This can be either performed by you if you control the set up of the study via API, or by Realeyes at any point, pre, post, or during collection. If you require us to create the grouped study for you then please simply send a ticket to support@realeyesit.com asking for us to create a new study that contains the data for X, Y and Z ads, including the original study names the ads come from if possible. In order to compare the two (or more) ads together on a single chart, simply:

1. Open the study page and click the 'Select media' button in the top left of the page. Select all media you wish to compare, and click 'Done'
2. Once the data for all of the ads you selected has loaded, ensure the 'Compare' option is selected in the 'Media' filter. 

Auto 'Summing' ads within a single study

Use Case: You have tested two or more very similar media (length and content) and wish to see their combined results.

Summary: Again like with the previous method this isn't true merging. It does combine the results of two or more ads together into a single chart line, but not permanently. If you were to refresh the page or deselect 'Sum' from the media filter (see Procedure below) then the data would no longer be merged. 

Procedure: This can be performed by you once two or more ads in a study have enough data (10+ sessions) to display the chart results, or at any other point during or post collection. If you require us to create the grouped study for you then please simply send a ticket to support@realeyesit.com asking for us to create a new study that contains the data for X, Y and Z ads, including the original study names the ads come from if possible. Once you have a study with all the required media in it, then in order to 'Sum' the results together, please do the following: 

1. Open the study page and click the 'Select media' button in the top left of the page. Select all media you wish to 'Sum' the results together for and click 'Done'
2. Once the data for all of the ads you selected has loaded, ensure the 'Sum' option is selected in the 'Media' filter. 

NB! Now that the chart depicts the combined ('Summed') results for multiple ads, the exports available on this page will also be for the combined results. 

Manual 'Summing' ads from different studies

Use case: You have tested two or more very similar ads (length and content) in different studies, and wish to view the combined results without creating a new study with all of the ads included. This would normally be if you wanted to quickly check what the merged results would look like, IE the task isn't worth the time/effort to submit a ticket for the 'Auto summing' option listed above. 

Summary: Again as with the last two, this isn't a true merging of the data. You are downloading the separate data exports for each ad, and then averaging them together to create your own version of the 'Sum' media filter result. 

Procedure: Open each study that contains one or more of the ads you wish to merge the data for, then perform the following steps: 

1. Select all the media that is relevant to you in each study using the 'Select media' button. Ensure the desired metrics (Happy, Engagement, etc.) that you wish to manually combine are selected. Furthermore, if you have multiple media selected within a single study, ensure the 'Compare' option is selected in the media filter. 
2. Click the 'Export' button just above the chart, and select 'Chart Data'. A CSV export will download via your browser that contains one column of chart data for each ad/emotion pair you selected for the chart. Repeat this step in every study you opened in step 1 until you have a column of results data for each ad you wish to combine.
3. Copy/paste all columns of data side-by-side into a single Excel spreadsheet. Create a new column at the end of the data, named 'Combined Data' or something else appropriate. You can then use Excel's 'AVERAGE' function to average the data across each row (each row being a second's worth of data) to get the average for that second. Do this for every row of data. 
4. You now have a combined data column from all of the included ads, which you can turn into a chart via Excel's charting functions. To make the chart line identical to what it would look like in the 'Automated Sum' option above, ensure the 'Smoothed line' option is ticked in the chart settings. This is not the same as the smoothing functionality we provide on all charts pages, it's merely a chart style option that makes the trend lines a little nicer to look at. 

NB! When you export the data, it will have already been 'Smoothed' to the same level you set it to in on the charts page. If you didn't specifically set the level, then it will be at whatever the default setting is. 

 Full database data merge

Use case: An issue with data collection resulted in you having two data sets for the same ad, however it's imperative that the data is merged so that it can be fully presented to your client as a single results set. 

Summary: The data needs to be manually combined by Realeyes developers. This is a big task and could take up to several days to plan and execute. The result will be a single study/single ad, but the results combined from two or more collections. This is a true merging of the data. 

Procedure: A formal request needs to be submitted to support@realeyesit.com that includes the following information: 

• A summary of what you are trying to achieve and why
• A list of the ads/studies you wish to combine
• The urgency of the request

To reiterate: This is a large, complex, manual process. It's not the type of task that can be done instantly or quickly - it must be planned into our developers' schedule. We may refuse the request if we do not agree that the justification for doing this is valid over the other merging options listed above. 

NB! If you have used *the exact same media file* for two or more collections, then you can simply request that we create a new study using those two (or more) collections.  If the media is the same in both collections then our system will automatically merge the results and depict them as a single chart line. This assumes that the media file is the same in all collections - if you uploaded multiple copies of the same ad and therefore used different files then we would need to do the full database data merge in order to get the study depicting the results fully as a single results set. 

For tech-only studies, should you want your demographic or survey data to be displayed on the dashboard, we will need you to send us a data file that includes all participant ids and any associated data. This way we can easily match the survey data you have collected with the recorded emotions data. The following protocol outlines best practices when sending a survey data file in order to ensure smooth upload:

• The file must be saved in .CSV format
• The file must contain a column for the Custom Participant IDs
• The file should contain columns for age and gender (whenever possible) for comparison to our demographic norms
• Our platform uses numerical values to translate data. If possible, please use number responses only in the data file and send a key indicating what the numbers in each column represent and how they should be labelled on the dashboard (see attached example)
• Any survey question columns that are left blank for certain IDs will be labelled as “unknowns” on the dashboard

Please see the attached example of a standard survey data file. The upload process is quick, so once you send the file we can have the data uploaded shortly after. 

If you have any other questions, please reach out to support@realeyesit.com.

Yes, we have a client-side component that can be implemented to check that all technical requirements are met. Please note, when using the checker it should NOT be downloaded to your own servers, but rather will be run from our servers. The full details on our Environmental Conditions Detection API are below.

Environmental Conditions Detection API

Realeyes uses webcams to read peoples facial expressions and behaviour. Although most new devices rolling out already have a webcam,
there is still a notable portion of users who don't have webcams to have their facial expressions read.

This can lead to the following annoying scenarios for users:

• Spending tens of minutes going through a lengthy screener or survey only to discover they can't do the study because they don't have a webcam when they get to the facial coding part
• Being routed to studies which require webcams several times in a row and being disqualified repeatedly
• Being asked to take part in a survey via a web page pop-up even though they couldn't possibly do the study in the first place

And the following scenarios for sample providers:

• Sample burn
• Low incidence rates

It's clear that this is an annoyance for the users and causes unnecessary burn for sample providers.

One option is to ask for existence of webcam manually as a separate question, but by our experience running webcam based studies we've noted that this doesn't work well. People sometimes don't even know they have webcams or don't care to answer correctly. This leads to a reduction in the number of people doing the study in the end.

Fortunately, all the capability to do the checks for existence of webcam and other requirements can be fully automated such that it wouldn't require any user intervention whatsoever. This makes it possible to make a quick and transparent check for capability of doing a Realeyes test and only invite or route capable people into the study.

Our Environmental Conditions Detector, a client-side script that uses flash to perform the required checks, is light-weight and easy to insert in webpages or surveys. The environment checker itself is distributed via the Amazon CDN to ensure it loads and executes at speeds which will not affect the user experience.

This component checks that:

• The respondent is using a compatible web browser
• The respondent isn't visiting the site from a mobile device
• The respondent has at least one webcam

These checks can be done fully automatically without user intervention and are unnoticeable to the respondent.

Possible usage scenarios:

• Integrated into a survey router before screeners so that only capable people are routed into webcam studies or studies where there is part which strictly requires a webcam access
• Inside a script that captures users from websites or other river sampling scenarios such that only capable people are asked to participate in surveys
• To automatically update data about the participant capabilities when they are updating their panel profile
• Integrated as the first step in the screener or survey script to make sure they don't unnecessarily waste time answering questions if they are not capable

Implementation and use of the Environmental Conditions Detector is simple. Insert the following JS script on which ever HTML page(s) you require, and replace the comments with appropriate code that executes the actions you desire depending on the result of the checks.

--------------------------------------------------------------------

Example Code Snippet 

<script type="text/javascript">

function _RealeyesitEnvDetectCallback(result) {
if (result.checksPassed==true) {
//Insert your code that handles a successful test here. It can be a
redirect to the webcam study or to store the result in a survey variable or
anything else.
} else {
//Insert your code that handles a failed test here.
}
}
(function() {
var e = document.createElement('script');e.type = 'text/javascript';e.async
= true;
e.src = ('https:' == document.location.protocol ? 'https://' : 'http://') +
'dvgs34yviqpzo.cloudfront.net/EnvironmentalDetectionAPI/latest/Realeyesit.Environme
ntalDetectionAPI.js.jgz';
var s =
document.getElementsByTagName('script')[0];s.parentNode.insertBefore(e, s);
})();
</script>

 

--------------------------------------------------------------------------

 

The script gets executed by the browser and result is returned to the callback function as an argument object with the following format:

 

------------------------------------------------------------------------------

Examples of Callback result argument

//In case when all tests are passed
{
checksPassed: true
,failureReasonCode: null
,failureReasonString: null
}
//In case when a check fails
{
checksPassed: false
,failureReasonCode: 4
,failureReasonString: BROWSER_NOT_CAPABLE
}

--------------------------------------------------------------------------

Possible failure reasons that we report: 

BROWSER_NOT_CAPABLE: 4

MOBILE_BROWSER: 5

NO_WEBCAMS_DETECTED: 6

OTHER_ERROR: 7

IOS_WEBVIEW: 8

UNSUPPORTED_BROWSER: 9

TABLET_BROWSER: 10

DESKTOP_BROWSER: 11

In 99% cases the component finishes all the script downloads and checks in under a second. There is a built in timeout mechanism which fails the check if for some reason it's not possible to get a result in 10 seconds, so in case the script file is downloaded, an answer is guaranteed.

A very basic example of the code in action is provided here: http://jsfiddle.net/realeyes/8JwAh/ you can easily modify and try out changes to the code to understand how it works.

If you have any questions about how to use the component or if something is not working, please report it to support@realeyesit.com

Usually, we see that webcam rates in online panels are around 70-80% if it cannot be targeted, and about 70% of people are willing to allow access to their webcam. There are a number of best practices to help optimize these rates: 

• Only targeting participants that meet all technical requirements.
• Implementation of our Environmental Conditions Detection API by panel(s).
• Optimizing the study invites to maximize the acceptance rate amongst respondents. 

Ensuring technical requirements are met

Because we use webcams to read peoples facial expressions, there are a number of technical requirements that must be met in order to participate. For instance:

• The respondent must have at least one webcam 
• The respondent must not have a firewall, or a firewall allowing outgoing RTMP/HTTP encapsulated RTMP protocol usage
• The respondent must be using a relatively modern browser

When possible, targeting for any of the above factors will help to significantly increase incidence rates. 

Environmental Conditions Detection API

Although most new devices rolling out already have a webcam, there is still a notable portion of users who don't have webcams to have their facial expressions read. We have an automatic detector in place within our tests to ensure participant's computers meet all technical requirements, however, the detector only runs once our opt-in page is reached. 

The recommended route is to avoid participants entering the test and answering your survey questions to only then be disqualified due to not meeting technical requirements when they reach the webcam opt-in page. To do so we have created a client-side component that can easily be included in survey routers, web pages or survey scripts themselves. The component checks that all technical requirements are met and returns a code which can be used to make better decisions in routing respondents. The result of the script itself is not stored or recorded anywhere, it simply appears for the client to make a decision on the next steps for participants that do not qualify.

Learn more about implementing our Environmental Conditions Detection API here. 

Maximizing acceptance rates

Lastly, maximizing the number of participants that grant access to their webcams will help increase IRs.

To maximize this group, we suggest not adding additional facial coding screens or opt-in language to your survey invites. Rather, stick to using our current opt-in page only, or minimal additions when necessary. We have found our current opt-in leads to the highest participation rates while still abiding to all privacy policies and security concerns.

Here is an example of the opt-in page participants see:

 

 

 

In order to monitor participants between platforms we must receive and pass unique Participant IDs. This helps us to tag participants from outside our systems in order to match up the emotion data we collect with any external demographic or survey data that you collect.

The ID must be passed as a variable in the URL called 'CustomParticipantID' and should be sent as a regular URL encoded GET query string. It can be any number or string up to 255 Unicode characters.

For example, in the following test URL, 'YYY' is the external tracking ID:  https://collect.realeyesit.com/XXXXXX?CustomParticipantID=YYY 

The ‘YYY’ at the end of the test link will need to be dynamically replaced by a unique participant ID, which allows us to upload any associated information that you send us after the data collection has been completed.

Yes, a full redirect method can be used to send participants from your survey or platform to our emotion measurement tests, and back again.

Create Your Test Link

The first step to running a tech-only study is to have a test link created for you. All of our test URLs take this form https://collect.realeyesit.com/XXXXXX where XXXXXX is replaced with a unique study specific hash. To have your test link created, login to your dashboard account and upload your video(s) to our Media Library. From there, reach out to our team and indicate the name of the video in the media library and any other test requirements. We will then create the test link and send it back to you.

Pass Unique Participant IDs

When redirecting participants to the test URL, a unique participant ID will need to be attached and passed as a URL variable called 'CustomParticipantID'. Find the instructions for passing unique participant IDs here.

Redirect Participants Back After Emotions Measured

Once participants either complete or fail to complete the emotion measurement test, they will be redirected back to your platform. Between 1 and 3 redirect URLs can be used to reflect the 3 potential participants flows in an emotion measurement test. These are Complete, Failed, & Declined, and the URLs can be edited directly via our Dashboard.

1. Visit: https://delivery.realeyesit.com/Collections/Index
2. This page will show all the Collections associated with your user account.
3. Select the Collection of interest by clicking on the corresponding ‘Edit’ button on the right hand side.
4. The edit page will open, allowing you to input or edit various aspects of the study, such as the redirect URLs.
5. Once finished, click the ‘Save’ button in the lower left hand corner.

 

 

As mentioned, we can accept up to 3 redirects, based on the 3 participant end states: Complete, Failed & Declined.

• Complete: This refers to a participant who fully completed the test. They granted access to their webcam, watched all of the test media, and finally had their results saved to the our servers.
• Failed: This refers to a participant who failed to complete the test. This is likely down to a hardware or software issue, such as not having a webcam, or an old and incompatible version of flash.
• Declined: This refers to a participant who declined to take the test. They either did not grant access to their webcam, or they quit the test before it had finished.

In terms of redirects, this functionality is useful for monitoring the participant's end states and retention rates. For instance, if a higher than average number of participants are declining to take the test, then it might be wise to change the language of the invitation or of the page that proceeds the emotion measurement test in the survey.

Passing URL Variables

There is an instructional panel on the right hand side of the Collection’s ‘Edit’ page the explains which Realeyes variables are available to pass back as well as how to do so via the redirects. It is also possible to send and have passed back any other variables, or to pass back static variables. 

However, any variables sent to us beyond CustomParticipantID will NOT be recorded permanently. They are stored temporarily and deleted once the participant’s session has terminated. Therefore we can accept and pass back any number of URL variables, but CustomParticipantID is the only variable that we store permanently.

Imagine that the following URL variables were required:

• CustomParticipantID
• Survey Platform ID (SPI)
• State (1 – 3 depending on whether they completed, failed or declined the test)

To have the 3 above mentioned variables passed back, the redirects will need to be as follows:

• Complete: http://survey.com?ID={CustomParticipantID}&SPI={SPI}&State=1
• Failed: http://survey.com?ID={CustomParticipantID}&SPI={SPI}&State=2
• Declined: http://survey.com?ID={CustomParticipantID}&SPI={SPI}&State=3

The variables could have any name. The ID, SPI and State variables in the above three URLs are simply examples. However there are a few points to remember:

• All variables are case sensitive when being referenced within {curly brackets}.
• The Realeyes variable CustomParticipantID must be named ‘CustomParticipantID’ in the collection URL that the participants come to the Realeyes test with.

Any additional variables that need to pass and be passed back must be identically named when sent and referenced. So if the collection URL has the variable ‘SPI’, then to reference that in the redirect it must be ‘variableName={SPI}’. Using ‘variableName={spi}’ will not work.