I’ve noticed that the Python tracker automatically attaches user_ipaddress to every events and it seems this is also the case for the other trackers as well. The official instructions specify that you can provide your own IP address by setting it in the subject field, but when it is left blank it seems it defaults to the actual IP address. Can this be turned off? I guess one solution would be to set the ip-address to a nonsense string?
Also in our previous Redshift instance, the ip addresses were anonymised by truncating the last numbers similar to what is described here. This does not seem to be the case for our new Snowflake setup? Is it the new stream collector or the Snowflake setup? I guess Snowflake has a built in masking functionality, but can we not store the ip address in plain from the beginning?
For the Python tracker, IP address collection can’t be turned off, but you’re right that you can set it manually to something like x.x.x.x. or 0.0.0.0 with the Python tracker if you’d prefer to do so. Note that this would mean that the IP lookups enrichment wouldn’t operate as expected. (Note that the feature to set IP address for server side trackers is usually for the opposite use case - to set the user IP address rather than the server’s one).
We do have a feature in the Javascript tracker that handles the removal of the IP address once the tracker and collector are done communicating with them.
Since the Python tracker is generally interacting with a server IP address rather than a user’s IP address, I’m not sure a similar feature is needed for the python tracker. But I digress…
Also in our previous Redshift instance, the ip addresses were anonymised by truncating the last numbers similar to what is described here. This does not seem to be the case for our new Snowflake setup? Is it the new stream collector or the Snowflake setup? I guess Snowflake has a built in masking functionality, but can we not store the ip address in plain from the beginning?
The collector and loader don’t have the ability to affect enrichments at all - the most likely explanation for what you’ve observed is that previously the IP anonymisation enrichment was enabled, but it is now disabled.
If you take a look into you enrichment configurations, there should be an anon_ip.json config file - which looks like this. Best next step to debugging is to a) check that it’s configured correctly, and b) check that the path is correct and has been provided to enrich.
This is exactly what I was looking for! This is however not possible for the mobile trackers?
The collector and loader don’t have the ability to affect enrichments at all - the most likely explanation for what you’ve observed is that previously the IP anonymisation enrichment was enabled, but it is now
Nice! There wasn’t a parameter for this in quick start example, but if you read the enrich-kinesis module, it is actually stated there. Would another option be to specify the anonymisation to all four octets?
I’m curious about this – could you please explain the use case how this feature would help you on the Python tracker? Server side anonymization is only a feature provided by the JavaScript tracker so far.
I think that configuring the IP anonymization enrichment to anonymize the whole IP address would be a good alternative if you want to apply this feature across all events.
We’re only using the JavaScript, iOS, Android and Java trackers, but I use Python under the somewhat false assumption that it behaves similarly to the others and because it is the easiest to set up.
According to this guy on the Internet, the Python tracker is becoming more similar to the other trackers going forward.
We are planning to standardise the features between the various trackers. The default configuration is certainly a point where we intend to work.
I’m not sure that is a safe assumption! The Python tracker does not have as many features as the ones you’re using. Yes, we are aiming to make all the trackers more similar, but that’s a longer term goal.