Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JN-1600] customer-specific mixpanel export #1443

Merged
merged 5 commits into from
Feb 4, 2025

Conversation

devonbush
Copy link
Collaborator

DESCRIPTION (include screenshots, and mobile screenshots for participant UX)

This adds a mixpanel token to portal environment configs. If set, and a custom domain is present, events in that domain will also be logged to the given token.

This also adds spring caching so that we don't have to load and assemble the config map every time an event is called. this is probably overkill for our purposes, but I thought it was a good excuse to dip our toes into using spring caching. Down the road, I could imagine us implementing a simple postgres-backed Spring cache manager so that we wouldn't have to do crude cache evictions based on timeouts.

TO TEST: (simple manual steps for confirming core behavior -- used for pre-release checks)

This is tricky to test in dev...

  1. redeploy admin app, redeploy participantApiApp with MIXPANEL_ENABLED=true
  2. go to https://localhost:3000/demo/studies/heartdemo/env/live/settings/website
  3. set the participant hostname to "demo.localhost"
  4. set the mixpanel token value to anything
  5. save the configs
  6. put a breakpoint in line 84 of MixpanelService
  7. go to https://demo.localhost:3001/
  8. after a few seconds, the breakpoint should be triggered, and you should see an event being created with your custom token

Copy link
Collaborator

@connorlbark connorlbark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I like that we still have our own mixpanel but our customers don't have to rely on us for insights.

delivery.addMessage(mixpanelEvent);
String eventDomain = getEventCurrentDomain(event);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not send the portal shortcode when tracking to avoid domain matching?

Copy link
Collaborator Author

@devonbush devonbush Feb 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose we could send portal shortcode and environment (we'd need the environment to not log sandbox events to their mixpanel)

<div>
<label className="form-label mt-2">
Mixpanel api token <InfoPopup content={<span>
If provided, events for participant interactions with the website will
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we specify that the events contain no identifiable information?

Copy link
Member

@MatthewBemis MatthewBemis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice! 🎉

import java.util.Map;

/**
* we don't want to have to go to the database every time an event is logged in our system to get the configs,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great decision to cache this

@devonbush devonbush merged commit 043583e into development Feb 4, 2025
18 checks passed
@devonbush devonbush deleted the db-mixpanel-process branch February 4, 2025 15:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants