Feature Request: Create a cookie option so FOLA volunteers and admins can omit themselves from our Analytics packages (Google Analytics and Microsoft Clarity)

[jelenaUX]

Problem description

We want a way to exclude or tag FOLA team members from our analytics so that we can make better decisions. Right now, our clicks are adding spurious data to our analytics. This is particularly important when we have low traffic as our use may make up a significant portion of clicks.

We currently (2023-09) have both Google Analytics and Microsoft Clarity analytics.

FOLA's Google Analytics data needs a more reliable way to identify and exclude FOLA volunteers and admins from the tally of website visitors. Currently we have two categories--"Phone Visitors" and "Desktop Visitors"--that explicitly exclude visitors who have clicked on obvious volunteer links: /login, /verification, /register, /opportunity, and /organizationedit. Despite this effort, "Desktop Visitors" still often includes FOLA volunteers because the volunteers may be testing something on FOLA website without clicking to any of those links. In particular, "Desktop Visitors" often include visitors who are likely FOLA volunteers/staff. For this reason, our Google Analytics reports have focused on exclusively phone visitors so far. This is a problem because "Dektop Visitors" represent about two thirds of FOLA's visitors overall.

Desired outcome In order to improve the quality of our Analytics data and our understanding of visitors looking for food (or people helping them) on desktop devices, set up a cookie that FOLA volunteers can activate in order to opt out of Analytics data collection.

• [ ] Follow the procedure described here: https://www.analyticsmania.com/post/how-to-exclude-internal-traffic-in-google-analytics-4/ (search for the heading "Excluding internal traffic based on a cookie").

  • [x] Set a cookie for internal users
  • [x] Set a cookie variable
  • [x] Create a developer filter in GA4
  • [x] Create a lookup table in GTM to override the traffic_type parameter
  • [ ] Test the filters
  • [ ] Activate both filters

• [ ] Find a way to block or tag ourselves for Microsoft Clarity

• [ ] Implement a way for FOLA members to set the cookie(s)

  • [ ] Interface Design
  • [ ] Set these cookies automatically once user logs into the site
  • [ ] Add a button on the log-in page that when clicked, sets the cookies on the user's browser. We would need to educate our FOLA members to click that button. It might be nice to have some indicator when the cookie is set or if it's already been set, but this is not MVP. Will need to educate FOLA team members to use this.
  • [ ] Or find a different/additional solution
  • [ ] Dev: Implement the above or other solution

Some caveats We likely can't exclude all FOLA users, but we can try to get most of them.

[ejstalker]

Updating this ticket with the news that this feature is in the testing phase. Our current GA deployment will set this cookie when folks visit the site via http://foodoasis.la/?internal_user=true. The cookie name is gtm_internal_user with value "internal".

[fancyham]

From Slack: Progress update:

June 25, 2023: Evan was able to find a way to tag or cookie users in GA using this method:

@ejstalker wrote: Hi FOLA folks, I've been handling a request to implement a cookie-based internal traffic filter for Food Oasis and would love your help to test it by visiting the site using the url https://foodoasis.la/?internal_user=true with tracking prevention disabled for the site. Please visit the site once from that URL and then once again from foodoasis.la. Thanks much for your help!

That url should set a new gtm_internal_user cookie when browser tracking protection has been disabled for the site. Let me know if it doesn’t work as expected! Using the cookie system within Google Analytics allows us to filter our analytics data. I believe there are templates for including a similar opt-in window but for the internal tracking cookie I didn't think we needed one since the cookie is only for us at FOLA and will only be set via a non-public URL. Lmk if you know differently! As to whether we need something like that for our overall GA implementation, that is a good question. I was thinking that this had come up before but if not we do definitely need to review our compliance responsibilities and make sure we're up to speed there.

@temrb writes: Doing it now the gtm_internal_user cookie shows up. I think to handle people that are using ad blocker, when person visits the internal_user=true page, if there is no cookie set, I would display a banner of sort turn off ad blocker to continue. As even if that cookie isnt set, they can continue to the site. Or make cookie mandatory through the cookiebot mentioned above I believe

[fancyham]

Revised issue to generalize this to all analytics packages, and added some user interface solutions once we are able to set the required cookies, basically: 1) Automatically set cookies once user logs into the site (which means they are a FOLA volunteer) 2) Put a button or link somewhere on the log-in screen (perhaps at the bottom) that lets FOLA members set the cookies.