{"_id":"5a3254fec049430012f55879","category":{"_id":"5bbc98ba817d5b00038e914a","project":"5587ff91b3bcf52b0051314f","version":"5a3254fdc049430012f5586d","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2018-10-09T12:02:02.151Z","from_sync":false,"order":1,"slug":"graph-and-methodology","title":"Graph and Methodology"},"project":"5587ff91b3bcf52b0051314f","user":"5587ff84b3bcf52b0051314e","parentDoc":null,"version":{"_id":"5a3254fdc049430012f5586d","project":"5587ff91b3bcf52b0051314f","__v":3,"createdAt":"2017-12-14T10:39:57.964Z","releaseDate":"2017-12-14T10:39:57.964Z","categories":["5a3254fdc049430012f5586e","5a3255199a6f2000125c0d61","5bbc98ba817d5b00038e914a"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.6.0","version":"1.6"},"githubsync":"","__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2017-06-13T11:14:25.101Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"Many, but not all of your User IDs will get linked in a Screen6 device graph for two reasons:\n\n1. Sometimes a User ID is the only ID of a person that is available in the source event level data, so there is simply no other User ID available to link it to.\n\n2. Our algorithms are not always able to find the behavioral patterns to confirm that two User IDs belong to the same person.\n\nThese factors define the coverage or match-rate of the device graph. The exact coverage figure may be defined in various ways:\n[block:api-header]\n{\n \"type\": \"basic\",\n \"title\": \"User ID or Event based coverage\"\n}\n[/block]\nUser ID based coverage is the percentage of all User IDs in the source data (more on that later) that has been matched to another User ID. Or in other words, the percentage of User IDs that has been assigned to a MatchID.\n\nEvent based coverage is the percentage of events in the source data (impressions, bids, etc.) that carries a User ID that is linked to at least one other User ID\n\nAs some User IDs may have been seen only once over a week and some others many times, these two percentages can be quite different.\n\nIf multiple types of User IDs are in the data (such as cookies and IDFAs), then the coverage percentages can be computed for each type separately.\n[block:api-header]\n{\n \"type\": \"basic\",\n \"title\": \"Look-back or real-time coverage\"\n}\n[/block]\nThe User ID or event based stats are computed as a percentage of User ID/events in the source data. The source data is the raw data that clients send to us every day. For statistics we look at two 'windows' within this source data:\n\n1. Look-back means the last day of raw data on which the device graph of that day was computed.\n\n2. Real-time means the next day of raw data, after the day on which the graph was computed.\n\nLook-back coverage should be used for cross-device analytics scenarios such as conversion attribution and campaign reach/frequency.\n\nReal-time coverage should be used for cross-device targeting. The real-time coverage percentages are usually slightly lower because new User IDs will be encountered that have not been seen before and as such, have not yet made it into the device graph.","excerpt":"","slug":"coverage-match-rate","type":"basic","title":"Coverage / Match-rate"}

Graph and Methodology

Real-time API

Coverage / Match-rate

Many, but not all of your User IDs will get linked in a Screen6 device graph for two reasons:
1. Sometimes a User ID is the only ID of a person that is available in the source event level data, so there is simply no other User ID available to link it to.
2. Our algorithms are not always able to find the behavioral patterns to confirm that two User IDs belong to the same person.
These factors define the coverage or match-rate of the device graph. The exact coverage figure may be defined in various ways:
[block:api-header]
{
"type": "basic",
"title": "User ID or Event based coverage"
}
[/block]
User ID based coverage is the percentage of all User IDs in the source data (more on that later) that has been matched to another User ID. Or in other words, the percentage of User IDs that has been assigned to a MatchID.
Event based coverage is the percentage of events in the source data (impressions, bids, etc.) that carries a User ID that is linked to at least one other User ID
As some User IDs may have been seen only once over a week and some others many times, these two percentages can be quite different.
If multiple types of User IDs are in the data (such as cookies and IDFAs), then the coverage percentages can be computed for each type separately.
[block:api-header]
{
"type": "basic",
"title": "Look-back or real-time coverage"
}
[/block]
The User ID or event based stats are computed as a percentage of User ID/events in the source data. The source data is the raw data that clients send to us every day. For statistics we look at two 'windows' within this source data:
1. Look-back means the last day of raw data on which the device graph of that day was computed.
2. Real-time means the next day of raw data, after the day on which the graph was computed.
Look-back coverage should be used for cross-device analytics scenarios such as conversion attribution and campaign reach/frequency.
Real-time coverage should be used for cross-device targeting. The real-time coverage percentages are usually slightly lower because new User IDs will be encountered that have not been seen before and as such, have not yet made it into the device graph.