Show HN: Cookieless Conversion Attribution with Pathview (pathview.io)
Morning HN.
I worked on a cloud CMS and then pivoted an analytics feature to a standalone SaaS. Pathview focuses on the conversion path rather than general analytics. I want to help users optimize conversions.
It doesn’t use cookies, contains 160-characters of JavaScript, and leverages HTTP Messaging for a modern take on an old-school analytics approach.
I’m close to launching a public beta test and could use a sanity check. Any advice, feedback, or questions for this first-time developer?
-sb
63 comments
[ 0.29 ms ] story [ 111 ms ] threadSome ad trackers use CNAME DNS entries, e.g. mytracker.mydomain.com points to tracker.pathview-analytics.com but adblockers also do the DNS resolution now, an arms race. (https://www.theregister.com/2021/02/24/dns_cname_tracking/)
But unfortunately, as far as my opinion goes, any kind of analytics and tracking just results in an instant "yuck" reaction, like a spider landing on my lap. I don't bother with analyzing it, I'll just try to get rid of it as quickly as possible.
The notion of privacy-friendly analytics has also been thoroughly burned by sleazy marketing departments outright lying. Or technical solutions that claimed to be privacy-friendly, but actually didn't really because of technical reasons. Or technical solutions being so complicated and obscure that it might as well be a privacy-protecting voodoo ritual for all a user knows.
In your opinion, is there a way to balance the need for feedback with respect for the user? What might that solution look like? Do you have any absolute demands?
For that perception to change, you have to educate users about their concrete, relevant and obvious benefit from analytics. I think this is hard or impossible. I also think that all the bad players in the market make this even more impossible, because you get lumped in with them.
I think the easiest solution is log analytics, preferably from anonymized or pseudonymized logs that are present anyways. That way, you don't collect any extra data, and as long as you do not keep the logs but only aggregated results, privacy isn't an issue. While a privacy policy and legal team need of course be aware of log analytics, the users cannot adblock it away, so that might be a plus. Also, no scripts, no cookies, no performance impact, etc. But of course the insight is limited by whatever is logged. Maybe some (privacy-preserving) data can be added to the URL parameters to augment the logs and provide a little more insight.
Another solution (that I just thought of, no idea if it would work) is that of recruiting users for testing your website under observation by the UI team. While this might invoke the image of recruiting 20 people off the street and sitting them down in a lab, I have something totally online in mind: Offer a voucher (or something) in return for participation. Participation should be instant. The users session should be connected such that the UI people on duty can see the website interaction (ala VNC, but limited to the website in question, so this should be possible by getting geometry, mouse position and keypresses alone via javascript). In case of difficulties, the UI team can interact with the user via voice chat (preferred) or text chat. After the user has finished their task, maybe ask them a few extra questions. You will gain much better insights, because you can ask for motivations and problems. You can point the user at the intended way and see if it works at all. But of course this approach requires lots of manpower and is technically challenging.
My absolute demands would be: Respect the relevant laws ala GDPR. Respect the DNT bit my browser sends. That way, you would already be above 99% of the analytics industry imho.
"Maybe some (privacy-preserving) data can be added to the URL parameters to augment the logs and provide a little more insight."
Pathview iterates on the server log approach. JavaScript collects two pieces of information: the current page and the referring page. The rest of the data is acquired by parsing HTTP Messages in real-time.
The only difference is cloud vs. self-hosted.
For example, it blocks a great many XSS attacks, as if every website had a strict content-security-policy header. Or if some joker on a website adds <img src="http://192.168.0.1/reboot-router.php"> or suchlike you're protected.
Websites that want to host sketchy untrusted content use iframes to external domains, so the sketchy content can't grab the user's cookies. If the website didn't trust the third party, why should you?
It can also block a variety of "features" that are actually annoyances - like third-party live chat popups, third-party cookie consent nag screens etc.
In terms of the price, how troublesome it is will depend on your web browsing needs. If you're a professional buyer visiting dozens of different companies' websites every day, you might find it inconvenient. But if most of your time is divided between your 10 favourite websites? Once you've got the whitelist right you'll barely notice it.
There are also anti-analytics filter list compatible with adblockers (default or opt-in) which might potentially add pathview in their database.
What would i need to do to be GDPR and CCPA compliant?
Those questions go completely unanswered and should be part of https://pathview.io/get-started . If those questions are not unanswered or addressed, the service is a liability. Answering those questions also gives a lot of transperancy to your customer what you are and are not doing. There should be an automatism and promise to inform people that an update to the privacy policy is required.
Pathview is about two months old, and the website is less than a week. Clarifications will be required, and decisions will be made. Thank you for the extra motivation.
Pathview strictly uses the salted hash to count unique visits. It's as minimally invasive as possible.
This system is focused on the source of the hit and the page views that led to the conversion. It could be used to measure organic search ROI for individual content pages. You could justify content spend based on performance data and plan future content based on past returns. I find this use case particularly interesting.
It is capable of multi-session attribution. From a product perspective, the tradeoff is timeframe for efficiency. The longer the historical perspective, the more costly feature becomes. This represents a current personal debate about tradeoffs.
Edit: Took 25 minutes but I pushed an update to the example report to highlight this point.
What is the right amount of information to share? Most users won't care but others will. I want to simplify rather than complicate. Finding balance is difficult.
Where do you store the salted hash?
I did build my approach around the Internet's backbone to future proof. Banning my approach would fundamentally break the Internet. I've made a note and will read into the precedent. Thank you for the research topic.
That’s simply false. The legal basis for processing an IP address in order to serve an HTTP request in the EU is Art 6 (b):
> processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;
This does not give you the right to use that data for any other purpose.
The approach you’re using is called fingerprinting in the industry (relatively naive fingerprinting given it only uses IP address) and it is the ongoing subject of enforcement action in the EU. Nothing about the approach is compliant.
Frankly, if it was this easy to forgo the regulatory impact of the GDPR, every analytics service would do it (many shady ones do).
The salted hash (of the IP address) is used for one purpose: to count unique visits.
For the purposes of compliance with the GDPR, Pathview does associate individual page views with a single real IP address. From the precedent set by the CNIL ruling on Google Analytics in July, the only way for an analytics tool not to process personal data in the form of an IP address is to relay the request via a first-party proxy (and strip the referer).
Your analytics tool cannot accept HTTP requests from the users browser and be compliant with the GDPR without gaining consent. Serving an HTTP request made for the purposes of analytics is processing personal data and there's no legal basis for the processing without consent.
> The fundamental problem that prevents these measures from addressing the issue of access of data by non-European authorities is that of direct contact, via an HTTPS connection, between the individual's terminal and servers managed by Google.
> The resulting requests allow these servers to obtain the IP address of the Internet user as well as a lot of information about his terminal. This information may realistically allow the user to be re-identified and, consequently, to access his or her browsing on all sites using Google Analytics.
> Only solutions allowing to break this contact between the terminal and the server can address this issue. Beyond the case of Google Analytics, this type of solution could also make it possible to reconcile the use of other analytics tools with the GDPR rules on data transfer.
Source: https://www.cnil.fr/en/google-analytics-and-data-transfers-h...
As I've said multiple times, I will be consulting with a lawyer to ensure Pathview is in compliance with relevant privacy laws. You might be a lawyer (who knows), but I am definitely not.
Each hit is stored without personal data but including a salted hash representing the IP. Users are not tracked and are not assigned any type of individual identifier.
The way to make it compliant is to ask permission for using the data. Or doing your analysis without any user identifiers, but that doesn't get you much useful insights.
I do have an idea that might work for this scenario. If I can calculate unique visits differently, I can drop the salted hash from the database too. I'm guessing that should be sufficient to satisfy most privacy conscious users.
Edit: I implemented this approach. It's less accurate but removes the need for any representation of the IP address.
Considering I'm about 2-months in, I'm happy with the progress and general direction.
a hash of an ip address could still be 'personal data' under the eyes of gdpr.
GDPR does aggressively define what can and cannot be done. As far as I know, I'm adhering to their definitions and guidelines. I will consult with a lawyer to confirm before I make claims about GDPR or other laws.
My goal is to make the best product possible given the constraints set. I believe there is middle ground between user privacy and analytics.
We did something similar for a project, which got approved by the relevant data protection officer: hash(IP + daily secret) as an identifier in the logs. This will be used to count unique visitors, the wraparound at 24:00:00 didn't matter to us. The daily secret is just a random number that our one (small setup) application server generates each day. It is never written out to disk or database, so an appserver restart also recreates that secret, it is strictly kept in RAM. That way, we could argue that, barring extreme measures like attaching a debugger to get the secret, we technically prevented deanonymisation.
But that was just a small-scale project, has never been tested in court and the usual YMMV, IANAL, ...
Edit: I think some webservers can be configured to do something similar
Seeing your answer, I have the feeling that this misconception is the basis for your project.