Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes. Many times, and at scale.

While not strictly accurate, it's easiest to think about it as a simple machine learning system. The system can't be interrogated, so you don't really know what correlations are being made.

The actual way it works is in layers. There's a human layer, using logic to create segments or other targeting methods. There's the ad network's automated optimisation options. FB really took this to the next level. There's retargeting. Bidding, and the economics of advertising plays a big role in giving the system intelligence. 3rd party ad management software.

Each piece/layer typically ads additional data to the set. The human/advertiser generally does this this by uploading or tagging their own customers. FB, for example, will allow you to create a "similar" list, where it finds user similar to those you designate. Similarity is somewhat ambiguous. FB/Adwords is where the heavy lifting happens, most commonly via bid optimisation.

The only intention is "goals per $." Price, and volume. As I said, the sausage factor is complex and no one sees the whole thing. In practical terms, a massive NN optimizing for sales/signups/etc itself is a decent analogy... and increasingly not an analogy.



Fascinating. Any clue as to what the largest factor for "similarity" is, and how much it contributes?


These tweets are a pretty decent sample, though I suspect these factors (association with other phones/users and such) are more active in bid optimisation than list generation. Hands off stuff is gradually overtaking the "hand coded" elements. These, I imagine, can take advantage of wider set of heuristics.

List generation is dumber, and feels more hand coded. Basic demographics, facebook/instagram interests.


How is this going to work with carrier grade NAT?

Edit: commercial to carrier, thanks justusthane


Just FYI, it's "carrier-grade NAT". And there are a lot of ways to associate people with each other other than their public IP address. The linked twitter thread doesn't even mention IP addresses, neither does the comment you responded to. I suspect IP addresses are already a pretty inaccurate way to link people with each other.


It likely doesn’t for IPv4 now that everyone has switched to HTTPS.

Many ISPs used to insert “client id” and other uniquely identifying information while NATting/proxying. Luckily, they can’t do that for https - but I wouldn’t put it beyond them to sell a back channel “connection xyz is unique user abc” service.

However, with the move to IPv6 , at least in my area, NAT is gone and static assignment is in. You just need to know the isp’s prefix length, and you get a unique identifier.


I think the question isn't so much how it works with that (as in you are pointing towards it just not working) and instead just how well it works with that.

Do you have numbers on how many consumers in say NA, various European countries etc are behind CGNs? I would guess most are used by mobile carriers (but I have no data) and I would gather that this particular technology is not going to be used to try and associate random mobile users anyway. It's more about who likely lives in the same household.


Google has that covered since many of those behind CGN are also on networks with native ipv6. Many mobile networks have already made the switch - dual stack to the handset with native ipv6 and ipv4 handled via CGN.

Googles interest in ipv6 isn’t entirely altruistic after all…


There are other identifiers that can work cross-device other than IP. Basically anything tied to you (identifying or not) that exists on both devices can be used.

Have you logged into a service or websites on multiple devices before? Then you voluntarily gave them enough data to link it.


Heuristics. Marketers do cross-device correlation only when seeing a small number of devices (ie. look like they could be part of the same household). If they see hundreds of devices behind the same IP it's probably a larger entity (ie. a company office).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: