An open discussion about embedding GA events into SYRIUS desktop for marketing purposes

[aliencoder]

Metamask is a business (ConsenSys). Syrius is not.

[mehowbrainz]

You’re changing your argument now. So it wasn’t about open source tools, but rather your personal issue with basic tracking to attribute marketing success.

I outline above what events are gathered by default vs. what we send as custom events – and outline the method to anonymize IP’s. Can you pinpoint which one is aggressive?

A marketer is only useful until the user succeeds in accomplishing first time tasks. The job was done, he interacted in a positive way for the network. Opting out of such solutions should be offered by default, yes. It can either be upon syrius installation or after. I’d much rather give the user the option from the get-go and let him decide if he wants to contribute to the success of AZ marketing to help grow the network.

[aliencoder]

I understand your concerns and I’m thinking of ways to implement them without affecting the privacy of the users.

And the tool is indeed open-source, but the server-side part is not.

Anyway, I think I have something in mind on how to do this properly (without adding Google in Syrius), but please let me research it first before presenting it over here.

[sol]

@aliencoder

without affecting the privacy of the users.

I’m curious what you mean by this. Mehowz is being cognizant of user privacy.

Are you anti-Google (rightfully so) or is there a concern that I’m not considering?

[mehowbrainz]

@aliencoder

but the server-side part is not.

You mean that the data gets pushed to Google Analytics?

Sounds like an issue about the network not owning all its data then, though the Zenon.Network PostHog data lives somewhere not open to the general public.

Any alternative will require a rewrite of the Attribute analytics dashboard.

[mehowbrainz]

In the meantime, I will evaluate the fit of using self-hosted PostHog, their API to rewrite Attribute, and their ability to send privacy-preserved events from within apps like syrius.

The last thing I want is for a solution to be debated by the community, it’ll cause a shitstorm. I’d rather propose an idea that’s 100% approved if it can’t be GA. Though this’ll delay everything. I’d probably be able to put Zenon.Org online with basic PostHog fast enough, but Attribute and marketing will be postponed.

[mehowbrainz]

Email sent to PostHog as I can’t find any details about features which allow to link in-app events to a previous website session, other than: Identifying users - Docs - PostHog

Will revert shortly, my team in the meantime has been instructed to halt Attribute related tasks and transition focus to getting the remainder of Zenon.Org Github issues completed.

[mehowbrainz]

Final update, the project will be placed on hold while @sol and I take the time to experiment with alternative solutions to GA (a seamless way to identifying users between web <> syrius desktop using PostHog so that we can attribute the in-app events to the marketing campaign).

This is what I’m gonna do in the meantime:

1. Will keep GA as I need it anyways for other Google tools i.e. search console for indexing etc.

2. I will get PostHog setup as self-hosted by the ZenonOrg infra engineer.

3. I will get PostHog events setup on Zenon.Org so events also send to PostHog (in addition to GA).

4. I will get Attribute’s link builder online so people can make links that’ll store user data to both GA and PostHog.

5. The Attribute analytics dashboard won’t go online for GA, will wait to see if we need to rewrite it for PostHog. Alien marketers will be manually granted rights to see the analytics as a temporary solution.

The rest will be for @sol and I to experiment with PostHog. We will try to come up with an elegant solution to make the web <> syrius handshake as seamless as possible (using PostHog), while prioritizing privacy and options to opt-out of analytics in a beautiful UX.

Zenon.Org will be launching soon with the Attribute Link Builder.

[0x3639]

I asked George what he thinks about this discussion.

[mehowbrainz]

@0x3639

I asked George what he thinks about this discussion.

What does @georgezgeorgez think of this: Google isn’t used, and an option to opt-out is offered from the get-go upon installation? Or a tracking-enabled version always has to be a sep binary?

[mehowbrainz]

Please vote on the controversial topic on Discord! Link to the poll:

Discord - A New Way to Chat with Friends & Communities

[0x3639]

@aliencoder

In my opinion it’s like implementing Google Analytics into the Bitcoin Core Wallet, utter non-sense.

What if we had the official wallet w/out tracking and another branch that was offered by the community with the opt in tracking option. Maybe the wallets could be branded differently… Likee SYRIUS Code and SYRIUS Community.

[romeo]

@mehowbrainz

• SYRIUS desktop application installation / setup
• First time Delegation
• First time Staking
• New Pillar spawn
• New Sentinel spawn
• New on-chain proposal submission (and the associated ID so we can track whether it was approved or not). This could prove to be incredible useful when headhunters are campaigning to attract talent into the network.

is there a way to track these actions on chain and somehow have Attribute store only the original conversion (i,e. wallet creation and note the address) - then use some code to link the rest of the conversions to the initial entry? For example, attribute stores that campaign X led to User Y downloading Syrius and creating wallet Z - then any on-chain activity from wallet Z could easily be linked to that initial conversion. The question then would be can you track wallet creation without embedding GA into Syrius.

It wouldn’t be full proof, as creating a second address wouldn’t be linked for example, but might be a good middle ground?

Just a thought

Appreciative of all the effort you’ve been putting into the marketing side of things @mehowbrainz

[sol]

@romeo

is there a way to track these actions on chain and somehow have Attribute store only the original conversion

I don’t think we want to do that. That’s getting close to personal information and we’re trying to stay away from logging any PII. I doubt users would appreciate having their funds tracked for marketing purposes.

Let’s pretend Google Analytics is no longer an option.
Mehowz is proposing PostHog and aliencoder will come back with his suggestion.
Everyone is welcome to express themselves and suggest other solutions.

In the end, the goal is to ensure privacy is preserved for consenting users. I want the whole process to be transparent, including a simple way for users to have their collected events deleted. Maybe we could also setup personalized webpages/dashboards that show users what has been collected.

Based on the initial results of the poll, more people seem to be in favor of optional, anonymous action logging. I think aliencoder might even be for this as well, as long as we’re not interacting with an abusive, centralized entity.

I don’t see a reason to fork the wallet over this.

Critics of this idea might be cynical because of overreaching corporate practices that gather way more telemetry than is necessary. We’re not about that. I hate spyware.

[mehowbrainz]

@sol

I want the whole process to be transparent, including a simple way for users to have their collected events deleted. Maybe we could also setup personalized webpages/dashboards that show users what has been collected.

This would require us to know which datapoints belong to which user/wallet (which we won’t intend to collect). We can always also just purge data after X time, but if the data is to be public and downloadable, anyone can store their own copy too.

We really just want to know: the person who visited the landing page as a result of clicking that Attribute campaign destination link, downloaded the wallet, installed it, and if he consents to be tracked also delegated. We should have no idea which address is responsible for the delegation and how much was delegated.

Though the latter brings up the question: Can someone with access to the analytic data compare the event trigger timestamp to the on-chain delegation TX timestamp? Without the quantity being stored, or the pillar chosen, can the analytic data be narrowed down to a range of transactions responsible for the event trigger?

If the answer is yes: we’d need to maybe randomly delay the event trigger to obfuscate the potential link between analytics and on-chain?

[sol]

@mehowbrainz

which datapoints belong to which user/wallet

I thought you needed a way to attribute Web->Syrius conversions via UUID. Is that id purged at some point?

[mehowbrainz]

Users would need to know what their user identifiers are in order to purge. Apologies misunderstood you.

From what I know in GA, there are options to request data deletion. Not sure about PostHog. GA below:

[sol]

For what I’m proposing, users won’t need to know their own UUID.
Syrius can keep track of it.
We’d have to research a way for the data to be deleted server-side; it might be possible (1, 2).

[mehowbrainz]

All sounds reasonable so far:

1. No interaction with an abusive, centralized entity (Google).
2. Self-hosted open-sourced tools.
3. Ability for users to purge their data.
4. Ability to opt-in/out of analytics on wallet installation, or at any point after in settings.
5. Anonymizing IP addresses.
6. Passing event parameters which are necessary to attribute the marketer success, while limiting potential exposure to on-chain comparisons.
7. Obfuscate analytical data via random delays (or other means) – as long as it doesn’t affect the analysis of the marketer.

[cryptocheshire]

Is this feasible without having to completely reingeneer attribute.me?