Jump to content

Cre8asiteforums

Discussing Web Design & Marketing Since 1998

  • Announcements

    • cre8pc

      Thank you! Cre8asiteforums 1998 - 2018   01/18/2018

      Internet Marketing Ninjas released many of the online forums they had acquired, such as WebmasterWorld, SEOChat, several DevShed properties and these forums back to their founders. You will notice a new user interface for Cre8asiteforums, the software was upgraded, and it was moved to a new server. Thank you for your support as we turn 20 years old.  
Sign in to follow this  
iamlost

Waiting on an eKstreme GDPR solution for the masses

Recommended Posts

Long time Cre8 member and ex-Googler extraordinaire Pierre Far (aka eKstreme) has over the years developed some intriguing software such as the Cligs URL shortener, more recently Blockmetry for understanding visitor blocking behaviours, now has in beta a prescient response to the EU's GDPR (General Data Protection Regulation) that goes into effect this 25-May.  

Given his previous endeavours I expect that this latest proffering will be, on the surface!, easy to use while handily fulfilling requirements. Said without having even had a glance at it - I'm that confident in the man!

I referenced his announcement back in November: Europe's GDPR: How Best To Adapt; More Questions Than Answers, Cre8, and have continued my own R&D into how best to keep collecting data while not transgressing. Given Pierre's choice of anonymity sets as a basis of compliance I took a second and a third look at a similar approach. However concluded they are more accurately an Anonymity Probability Distribution and as such may or may not actually be anonymous, i.e. indirect re-identification. Further, the very creation of many/most (I am NOT speaking to Pierre's implementation, not having seen it) Anonymity Sets deliberately loses information to aid the data anonymisation process, i.e. loosing the last octet in an IP address as 54.230.44.134 becomes 54.230.44.xxx.

As I have been using the BLAKE2 cryptographic hash function as a check that uploaded website files have not been compromised it seemed that immediate hashing of all PII (Personally Identifiable Information) and indeed all of a visitor's 'fingerprint' data within a hash tree structure just might allow it's continued collection while simultaneously incorporating pseudonymisation.
Note: the GDPR differentiates anonymisation and pseudonymisation and requirements differ accordingly.
---anonymisation means, basically, that identifiable data is destroyed and can not be directly recovered.
---pseudonymisation means, basically, to substitute identifiable data with a directly reversible, consistent other value.

The only 'fly in the ointment' is that I also have a methodology for calculating when a return visitor arrives via a different IP, device, etc. that does not easily play nice with a hash as prior identifying fingerprint input. So far I've been testing various ideas of how best to compare individual hash tree leaves to accomplish the same goal. Live, on the fly, without noticeably slowing or interrupting visitors' experience. Where fun and headache meet!

I have two quite different PII data collection behaviours:
1. the real thing aka name, address(es), phone/email, credit card, etc, that is collected via affiliate presell to pre-fill forms on a merchant's and/or payment gateway's site. I do this because it is a significant conversion rate increase. I could:
* stop doing this and simply refer the visitor to the often poorly designed confusing merchant/gateway forms. A serious privacy Damocles' sword issue vanishes. Conversions drop by low double digits.

* continue as I have been doing, easing the visitor experience, while simply passing through collected data that is wiped on return receipt of checksum or 60 minutes. The main consequences would be, as now, securing the PII data while in transit and, a new requirement, appropriate advisory to the visitor prior to their sharing such data. And, as a marketing, not regulatory, necessity notify them when the data has been successfully transferred and subsequently wiped.

I'm currently running both to iron out kinks and nail down consequences. What is behind door number three?

2. I have come to rely on a rather extensive visitor/device fingerprinting methodology to (1) recognise return visitors and (2) provide contextual content delivery. Nothing as overt as name or address or email (except for double opted in newsletter) and certainly not credit card  or similar information. However, IP is potentially an identifier (and is so considered by the GDPR) and so are other collected data.

I use the information collected as (1) offline analytics data mining and various R&D methodology enhancements and (2) live on public facing servers as mentioned earlier. Losing some to all of it would pull out the very foundation of my systema. So the choice discussed earlier.

On the public facing servers hashes should provide sufficient PII data protection; the R&D servers are not connected to the internet, and I'm the sole mucker about. Which leaves again, appropriate disclosure and audit methodologies. Good gracious but the law-type-people have been having a fine old time. However, the end result should be seamless and compliant.

Most webdevs don't have the need nor the interest in all the stuff I enjoy so here's hoping Pierre's software is the golden ticket to ride, it most certainly will be less expensive!

  • Like 1

Share this post


Link to post
Share on other sites

The technical discussion above is beyond my knowledge and expertise and leads to consider this recent/current thread.  I suppose my difficulty is more a function of it being above my technical knowledge than non readability.

Regardless I'm signing up for Pierre's beta.  I'll connect it to one or more of the local smb sites we operate.  Based on a prior thread here, spurred by a tweet by Pierre and Iamlost's catch and reference of it...I'm concerned specifically about the growth of "direct" as a reflection of both Google Analytics and other Analytics.   Over time the percentage of traffic assigned as direct has soared for our sites.  Its far more prevalent on mobile traffic than on desktop.  I assume its a function of apps, of traffic such as Apple Maps from an Iphone and other sources.  

As much as our local service sites have seen this growth its explosively worse for local restaurant sites, comprising very extensive elements of all traffic.  One little find after some investigation....traffic on urban restaurant sites that I've seen that are designated as Direct are probably often coming from things like mobile local/regional restaurant menu apps..  If you isolate traffic from a Safari browser labeled Safari (in-app) a very large volume of that traffic for restaurant sites lands on the www.restaurantname.com/menu page.  In millenial dominated urban areas popular apps for food delivery/ getting to menus, the yelp app etc are delivering traffic to restaurant web sites, and delivering purchases.

Revenues are coming in to restaurants via delivery services, Open Table and other reservation systems, etc....and frankly the web and specifically Google Analytics aren't catching it at all.

Share this post


Link to post
Share on other sites

Yay I can post again!

Wait no more @iamlost. Full details and sing-up: https://blockmetry.com/

The product *is* very easy to use, and the output is a database - your database because it's your data. You give Blockmetry write access and you get data in real time. 

For what earlpearl is talking about: There are *many* ways an app can identify itself _if it so chooses_ (big caveat, this), and a few ways to share it's an app but not say which one. The analytics platform needs to look for all these and make sense of them. Blockmetry does.

GA doesn't.

I don't like GA (much).

P

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

@eKstreme you are turning Blockmetry into quite the analytics engine. Congratulations!

If I wasn't already so far down the dark path I'd be thrilled with the offered capabilities. However, the double edged sword that is user experience::contextual delivery <-> personalisation::conversion rate... is such a fantastic tool... The differece between targeting segments/groups and individuals is considerable. That most webdevs don't even segment is my competitive advantage and makes referrals from my sites, be it ad or af, worth multiples of other sites' traffic value. Blockmetry, while a huge step forward for many/most would, regrettably, be a step back for me.... and the abyss does sing, you know.

Hey, Kim, you should talk Pierre into letting Cre8 be a test bed so that I can break play with it!

 

  • Like 1

Share this post


Link to post
Share on other sites

But sir, @iamlost, you're implicitly making a wrong assumption. Hear me out.

There is nothing stopping you from continuing to do what you're doing now and add Blockmetry as a separate data stream. What Blockmetry allows you to do is have two data streams under different legal bases (under the GDPR, and Blockmetry would help you use legitimate interest). Please do sign up with your own site and break it yourself :)

Secondly,  and I'm going to write about this properly in the next few weeks, is that we're increasingly dealing with a mixed (heterogeneous) blocking environment. Imagine a browser that's content blocking. They go to a website that asks blockers to disable the blocking to view the content (this is happening more and more). The user does, sees the content and your ad. The user clicks on your ad, using their blocking browser, and lands on your site. You don't see them if you're using the usual third-party platforms (they're blocked), although you're charged for the impression/click. Blockmetry would see that and you'll get a more accurate read on the performance of this campaign.

Going back to the assumption you're making: Blockmetry and other platforms don't have to be used exclusively of each other.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×