Potential for Misattribution In Call Log Saved, Written Down or Transferred Dynamic Numbers
Hello,
I am wondering if anyone can give me insight into whether they have encountered any potential for misattribution in users writing down or transferring dynamic numbers to other people as well as users on desktop dialing on mobile phone and saving it in a call log for later. My main niche is an older demographic and higher ticket so we suspect a sizeable amount of people are passing tracking numbers on to their family members, writing them down, dialing them later on a mobile device or saving it to a mobile device call log for later. Does Call Rail have a "data match window" or a "data match duration" outside of which the misattribution risk will be very high? If the original user who writes down/saves to log/forwards to family a tracking number calls it at their leisure later and it is currently checked out by an active user on the site will the original user be given the marketing data of the active user? This may be a newbie question sorry.
Dave
Comments
Hello Dave. There is the possibility for misattribution if a number is written down or transferred to another person and dialed later. We do not have any way to know who originally wrote or transferred that number and we cannot properly identify a later caller. In practice, we find that the vast majority of people will call within 15 minutes of visiting your website. If they do not call in 15 minutes, they either will not call or write the number down for later use.
There is no data match we can run in this scenario. We need to identify callers by their web session data to make a match. When somebody passes a number on or saves it for later use, we do not have that web session data to match with. If this is a constant theme then the best solution is to add more numbers to your website pool, but this solution is more of a bandaid, since some callers may save the number for weeks before calling. I hope that this answers your question.
Thanks for your reply,
So situations like this are non-session related and DNI tech can't be modified to account for non-session related tracking. If you double or triple the recommended number pool you are increasing the chances that the written/dialed/transferred tracking number will be unassigned as they are sequentially assigned. Each "larger than necessary pool" has a "percentage of un-assignment variable" associated with it that increases with the size of the pool.
This is correct Dave. Ideally, a website visitor would call within about 15 minutes. If a visitor writes down the website number and calls a month later, their source will show whatever the last visitor's source was that saw the same number. It will not be accurate. However, we also place a cookie on the browser so that if the visitor from 1 month ago returns to your website, they will see the same number as before and we will attribute the call to their original tracking information. In short, writing down the number for later use can lead to misattribution, but if the caller visits your website again to get the number later, the call will be properly attributed.
Thanks for the update.
Is there any mathematical proof that supports the argument that increasing a pool size by x amount would decrease the likelihood for misattribution by x amount because of probability of being unassigned?
Hello Dave. The mathematical idea behind having enough numbers in your website pool to cover the same amount of visitors in a peak 15-minute period is a time-tested one. It works for 99%+ of our clients. However, if somebody writes the number down and calls later, there is no way to guarantee that attribution will be correct. It will be correct if they visit the website again and call then, but not if they call the number from a piece of paper or from a cell phone contact list. Increasing the website pool size is no guarantee that you will avoid misattribution if somebody calls a number they wrote down a month ago. There is no way to differentiate that caller from the most recent website visitor.
Please sign in to leave a comment.