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

This thread acts as a discussion space for implementing and experimenting-with event triggers in the desktop SYRIUS wallet.


Integrate basic events in SYRIUS desktop wallet using the Firebase Google Analytics integration: イベントをロギングする  |  Google Analytics for Firebase

What are GA events?

In Google Analytics, an event is a user interaction with your website or app that you want to track. Examples of events include a user clicking a button, viewing a video, or making a purchase. When you set up event tracking in Google Analytics, you can collect data about these interactions and use it to understand how users engage with your site or app.

Zenon.Org’s GA events:

The website and campaign landing pages has events for every button/link/interaction available, meaning that whenever a visitor visits the website or a specific landing page, any interaction he makes on the website is recorded into Google Analytics.

Is the visitor’s IP address stored into Google Analytics?

Yes and no. We enabled anonymizeIp in the Google Analytics tag, which is a function in Google Analytics that removes the last octet of the IP address prior to its storage. This means that the IP address of a visitor to a website is not stored in its entirety, but rather with the last octet removed. For example, if a visitor’s IP address is 123.456.789.123, it would be stored as 123.456.789.0 after anonymizeIp is applied.

The purpose of anonymizeIp is to protect the privacy of website visitors by reducing the amount of personal information that is collected and stored by Google Analytics. It is important to note that anonymizeIp does not completely anonymize the IP address, and it is still possible to use the remaining information to approximate the location of the visitor.

More details: [UA] IP masking in Universal Analytics - Analytics Help

Can I verify if the anonymizeIP function is truly enabled for the landing pages I’m promoting?

Yes, there are 2 methods to verify this (once is live):

  1. Using
    a) Add the domain to A new window/tab with will pop-up.
    b) Click on the “G-M2F8KJ59YQ” button at the top.
    c) Click on “Config” on the left pane.
    d) Expand the “API Call” window. You’ll find:
    gtag("config", "G-M2F8KJ59YQ", {anonymizeIp: "true", send_page_view: true})

The 2nd method:

  1. Using your browser’s network console:
    a) Open developer inspector tools in your browser.
    b) Click on the “Network” tab.
    c) Load
    d) Search for a request URL starting with “
    e) Locate anonymizeIp=true in the request URL.

Why integrate GA events into SYRIUS desktop wallet?

So that Attribute.Zenon.Org can publicly display event data, and marketers can calculate their costs for acquiring event conversions, including the cost to acquire:

  • 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.

What is Attribute?

Attribute was developed by mehowz, Amin and Hoori while at THORChain. It’s been since adapted for Zenon.Org. Google Analytics data is hidden behind an account-permissioned dashboard, requiring Administrators to manually add users in order to grant them permissions to view data.

Attribute pulls all the relevant Google Analytics data into a public dashboard for everyone to see, eliminating the need to ask for permissions into Google Analytics.

A marketer could then filter the data to see whether his campaign / zenon address generated some specific clicks on which led the user to the Zenon Discord server – or better, whether his campaigning of a SYRIUS download landing page, lead to some new installations of the wallet. He can then calculate how much $ he spent to acquire each new installation, and gauge whether his marketing campaign can be scaled to drive value to the network.

Aside from the analytics data on Attribute, users are given tools to generate special campaign links which’ll attribute their zenon address as the one responsible for the event triggers / conversions.

Can event triggers be gamed/faked?

Yes, and in order to fight this, will implement Google reCAPTCHA for the most important events, for example: prior to a SYRIUS wallet download, a user will need to complete a reCAPTCHA puzzle to trigger both the GA event and file download.

Zenon.Org also uses a reverse proxy to mirror and cache its website, with CAPTCHA challenges triggered automatically upon bot detection (machine learned techniques), increasing the difficulty.

Why does it matter if event triggers are gamed/faked?

For data integrity, and to avoid draining funds via potential future smart contracts designed to pay marketers for events attributed to their zenon address.

What would the marketer be able to determine aside from the cost of acquisition, if such events would be integrated into SYRIUS desktop wallet?

  • The strategy, channel, source which drives the most event conversions.
  • The user’s path leading to an event conversion.

How do you generate a trackable Attribute campaign link that’ll attribute me event conversions?

Using, select a landing page you’d like to generate a link-for, fill in the cells on its right, and press “Click to Build Link”. You can create as many links as you’d like with the same zenon address. We’ll likely add a reCAPTCHA in order to avoid spamming / wasting inventory of built links.

Where can I use such Attribute campaign links?

When sharing Zenon to someone new, rather than pointing them to, give them your Attribute link (which you’ve generated for yourself for the landing page). You can use such links in your Twitter bio, Twitter threads, Telegram, Discord, articles, advertising campaigns etc. Ideally no one should never be driving traffic to links directly, but rather always through branded Attribute campaign links.

How do Attribute campaign links look?

We use alternate domains in order to protect the official domain, which include:
(others can be added)

An Attribute campaign link could look something like:

How long before events appear in Google Analytics?

Typically within 6-8 hours, however it’s possible it can take up to 24 hours for data to appear in Google Analytics.

What are the limitations?

Some browsers like Brave won’t trigger Google Analytics nor its events. Ideally a marketer should be aware which audiences it targets.

Where are Attribute’s Link Builder links stored? Can they be modified?

Attribute uses a 3rd party link shortening service to generate its links. In the private dashboard, anyone with my admin rights, or the technical teams behind the shortening service, can modify the links generated by users. I doubt this would ever happen, would be a major breach of trust by the provider. Will read their TOS to confirm this.

I cannot modify Google Analytics data.

When will Attribute and Zenon.Org be online?

Our backlog includes the following:

  • Getting Attribute back online, and pulling existing Zenon.Org data. The Zenon.Org domain is operating behind a dev URL. A bunch in the community have seen the website and can provide testimonials.
  • Getting graphics finished on the new Zenon.Org desktop and mobile websites.
  • Displaying some on-chain metrics on Zenon.Org
  • Setting up reCAPTCHA amongst a few other minor open issues.
  • Ideally setup the ability for anyone to add a retargeting script while building an Attribute link so that they can capture their own audience / traffic, and retarget them in various networks to drive attention back. This one will likely be rolled out at a later date.

We’re very close, it’s been worked for months. The mobile website will be going live at the same time as the desktop website. The whole is built as a framework, can create tailored landing page extremely fast to cater to the needs of its public marketers.

I’m open for all questions / comments.



Amazing work so far! I’ve seen the desktop and mobile pre-production builds for Zenon.Org and they’re really nice! :clap:

Will there be a marketer/participant rewards system setup for launch or are those details still tbd?

Do you have any dependencies regarding changes to Syrius?
What is your ideal timeline for launching the website and GA events, together or separately?

Also, really nice work with My only feedback is to maybe add a button that builds all (possible) links for marketers, and the results could be output as json to reduce the amount of manual clicking.


This requires thorough evaluation and IMO improvements to the Attribute infrastructure. More importantly, the gaming part is always concerning so we’d have some work to be confident about such system. Though the payment layer risks could be passed onto another tool if we opened an API to the data. I’d like to improve the UX and see it all in action before considering proposing such payment solutions. I will personally be using grassroots marketing methods to promote Zenon at the start, with no assurance of payment from the network for my contributions.

I’d like to see Zenon.Org + Attribute live first before we consider adding any events to the wallet. Ideally we let the community build Attribute campaign links, let them see their data appear in the dashboard to understand its power.

I’d also like to write a library of events in the for Attribute in the HyperGrowth section: it’ll allow for marketers to understand what an event value means i.e.

an event called “content_syrius_macos” means that the visitor who visited the website using your Attribute link, clicked on “Download syrius v0.0.5-alphanet release (latest) for macOs”

Eventually embedded SYRIUS events would have their own classification i.e.:

“syrius_desktop_v0.0.5_alphanet_install_complete” or
“syrius_desktop_v0.0.5_alphanet_delegate” or

The developer implementing this can collaborate with me to request AZ funds for himself. I won’t be asking for anything from AZ for myself for the SYRIUS implementation. If we can test this prior to any submission/promises are made, it would be ideal. Nothing beats demonstrating the full cycle of the product first.

We’d have to come up with the list of events everyone approves i.e.

  • 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.

My hope is within weeks or sooner. Zenon.Org can be launched today, it’ll just be missing some on-chain data on 3 pages, and graphics will be missing.

Attribute worked while used for THORChain, so given its re-configuration goes smooth, I don’t see it taking too long to get the infra deployed. 98% is ready.

Values entered in cells can be dragged down for multiple columns (just like you would with Google Sheets), it was designed with power-users in mind. Good idea for a “Click to Build All Link” function, will add it to the backlog.


This entire initiative is awesome. Do you have any high level results / improvements from THORChain after you implemented the site there?

I would like to see events / actions embedded in Syrius, but I’m a little worried about privacy concerns. They don’t bother me, but I’m worried the admin of zenon-network will not merge this function. Is there any way to remove more of the IP address?

On the flip side, every website on the planet records IP addresses in some log file. Hiding part of the IP is 90% better than the rest of the internet. BTW - look at the default log file for NGINX. they don’t hide anything. Food for thought.


I originally built this to prove that we can measure the cost to acquire a swap / pool transaction in a web-based THORChain DEX (because Google Analytics supports cross-site setups, where user sessions are shared between completely different domains). We were able to measure the size of the transaction, fees, which assets were swapped etc. Given it was all rigged so that another DEX in the ecosystem would be the leader, the tribal community didn’t use the tool (other than a bunch of my supporters). This was all leading towards me leaving that ecosystem (and a bunch of other political issues). still logs all the events triggered to GA. If you look at “Internal Links” and “External Links” rows/columns, those are the totals since events were added:

External Links:

Internal Links:

Kinda tells you what was most important to browsers…

That’s the most we can do from Google Analytics, but perhaps we can find other ways to strip IP details on the application side (the website / landing pages). Though we’ll lose all geographic analytics.

I agree, I bet ya GitHub knows everything about every single person who downloaded SYRIUS or any repo.

The implementation would just need to be thoroughly reviewed to make sure nothing sensitive gets passed to Analytics, but really it’s quite simple of an integration: it’ll pass only what you instruct it to pass…

1 Like

Many product implement events into their apps to improve UX. If they can track what features are used/not, they can change the shape to accommodate. But that’s another story, I won’t get into that yet… baby steps lol.


The same implementation can be done for SYRIUS chrome extension, but the desktop version is more stable and complete… and likely more widely used. Though there will be benefits to also have such integration in that extension. There’s features in Firebase called “Deep Linking” which would allow landing pages to trigger specific views of a wallet, directing traffic better to complete an on-chain transaction, while measuring events.

Firebase supports a bunch of cool stuff like In-App Messaging, A/B Testing and more.


This is a great initiative as I can clearly see the value derived from GA in our marketing efforts. Here are some thoughts that have less to do with the implementation, but more with the idea.

For me personally, I would love to see this initiative 100% in the chrome extensions wallet and the mobile wallet (instead of syrius desktop), and develop it to be on par (UI/UX wise) with syrius. There are two main reasons for this. Firstly, syrius is the only wallet currently where you are not forced to depend on others infrastructure, you can run your own embedded node. Correct me if I’m wrong, but that is not the case currently with either the chrome extension or the future mobile wallet. For this reasons, since there is already a third party that will be possibly gathering this data, there is no compromise in privacy from this GA initiative if we just added it to these two wallet types. We get the same benefit, and none of the drawbacks.

Another small thing would be regulation, I’m not familiar with the laws but GDPR is a big deal in EU for cookies and stuff and I’m not sure how this interacts with open source software with no entity responsible, but something worth looking into. Maybe it would just be as simple as a consent checkbox and Google/Alphabet takes care of the rest.

Secondly, In the implementation side, I’m a bit concerned with software bloat and how it’s effects on syrius performance. Would it make sense for the community to keep and maintain two repos for syrius (with and without GA type addons) or could it be as simple as having the features disabled to not hinder performance, it would just increase syrius file size?


Limiting to the chrome extension reduces audience targeting (chrome users exclusively), and IMO the extension is incomplete. As far as the mobile wallet, which one are we referring-to?

Using metrics we can campaign to attract local embedded node operators, an important role which could help decentralize the network further.

IP’s are anonymized, so Google shouldn’t get the full IP address as per their documentation. If these are concerns, we should also examine whether GitHub stores any analytic data when we clone repos or download files from /zenon-network.

Will look into this.

I’ve seen the implementation on and it’s light. What the idea asks is just a few triggers for key events which can help marketers validate their efforts. @sol can validate whether such implementation will affect the performance of the wallet (but I doubt its impact can be felt).

We should also look at the benefit of such a light implementation:

  • Marketers will be able to confidently claim success for their campaigns, using permissionless and open tools. I wouldn’t recommend to give a marketer a dime unless he can prove that his campaign results in performance valuable for the network.

If the community doesn’t agree to a light implementation:

  • Marketers will only have the ability to build marketing lists via form captures (emails, names etc), and campaigns will never be able to truly prove what they’ve driven for the network (aside from behavioural event triggers on landing pages, form captures).

Here’s a sample basic custom event which gets sent to GA:

await FirebaseAnalytics.instance.logEvent(
    name: "syrius_desktop",
    parameters: {
        "event_category": macos_setup,
        "event_label": PoC,
        "value": installed,

Google Analytics receives the data that it’s instructed to receive as custom events, and we pick the moment the event gets triggered within syrius.

The following parameters are collected by default with every event, including custom events. The automatically collected events that don’t have parameters listed in the table below only receive the following parameters:

  • language
  • page_location
  • page_referrer
  • page_title
  • screen_resolution

I don’t think it’s a good idea including 3rd party code into Syrius (especially closed source from Google).


May you elaborate on the specific risks of the Firebase implementation? It’s a vague statement.

Why not? Do you understand what the integration actually consists of and how much it can help track user behavior and improve adoption?

Have you seen what e.g. metamask tracks in comparison?

Are you opposed to the inclusion of Firebase, the use of Google Analytics, or both?
Do you have suggestions for alternatives to OP’s proposal?

At the very least, I think we will need user consent that can be toggled on/off at any time to track their activity in the app.
Additionally, if GA is used, we should be aware that Google is banned in certain countries.

1 Like

I think aliencoder has valid concerns. Sol can correct me if I’m wrong, but in order to apply the few lines of codes required for the GA capabilities we need, we have to reference, and therefore “download”, closed source code that is hosted in Google servers. It’s like pointing to a javascript library in order to use it inside a webpage. This kinda goes against our Open source ethos and could potentially be a vulnerability in the future.

I’m not aware if there are open source alternatives. Certainly not as good as Google Analytics can be. I will keep pushing for us to try to improve the chrome extension and get blaze to give us a MVP mobile wallet in order to add firebase to those two options. The reasoning is simple:

These two wallets will need an entity to publish them in both the play/ios store and in the chrome store for browsers. This is really good, as now we have someone liable for the compliance of privacy laws. Additonally, these two wallets will naturally suffer from centralized node infrastructure, which basically becomes infura for Metamask and could collect users data, so adding a a tracking tool for marketing purposes does not make it any worse.

Just my thoughts.

I’m not familiar enough with GA to know if they circumvent our configurations (i.e. collecting a vast array of detailed datapoints vs our privacy-oriented scope).
I was under the impression that they collected what we chose to send them, and Firebase is open sourced.

Here are some GA alternatives.

Has to be Google Analytics, otherwise the Attribute technology will not be able to tie the website visitor to the event sent from within the app. Firebase is the only tool which does the GA integration. Otherwise if not Google Analytics, Attribute will have to get completely rewritten to support another analytics software.

Though I don’t get the concern is, I outline the method used to anonymize IP’s. If we want to lead AZ marketing in the right direction, we need basic data-driven privileges in wallets. Otherwise we’ll be approving proposals which’ll never fully prove the conversion the network most desires. IMO it’s worth experimenting-with locally to demonstrate its potential and data capture.

The following parameters are collected by default with every event, including custom events. The automatically collected events that don’t have parameters listed in the table below only receive the following parameters:

  • language
  • page_location
  • page_referrer
  • page_title
  • screen_resolution

@aliencoder looking forward to real good arguments to wanna exclude the open source firebase library from the syrius codebase… firebase_core and the firebase_analytics plugin.

Here are details about what’s open sourced from Firebase:

1 Like

No, Firebase is open sourced:

Here’s the repo: GitHub - firebase/flutterfire: 🔥 A collection of Firebase plugins for Flutter apps.

Likely the plugin to be used: flutterfire/packages/firebase_analytics/firebase_analytics at master · firebase/flutterfire · GitHub

Yes. I think embedding Google into a non-custodial “neutral” wallet that is the de-facto implementation for a decentralized network defeats its purpose.

I understand that you want to track conversions, but it’s way too aggressive to implement tracking directly into Syrius.

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

On the other hand, we can propose other solutions where users can opt-in for tracking.