-
Notifications
You must be signed in to change notification settings - Fork 259
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
[Analytics] Track install and error events #1984
base: trunk
Are you sure you want to change the base?
Conversation
*/ | ||
logTrackingEvent('step', { step: step.step }); | ||
|
||
if (step.step === 'installPlugin' && (step as any).pluginData.slug) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this account for blueprint.plugins
? Or just blueprint.steps
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both. It will run whenever a step is completed.
During Blueprint compile, blueprint.plugins
is converted to steps.
packages/playground/website/src/lib/state/redux/boot-site-client.ts
Outdated
Show resolved
Hide resolved
What's the advantage of logging error events to GA instead of logstash as @brandonpayton once suggested? And how would we use GA to aggregate and analyze the error information? |
This PR won't log errors in GA, only an event that indicates an error occurred. I would love to have Logstash for debugging! What we have in Slack today isn't great. |
I don't recall the exact context, but IIRC, I think my intent was to point out what was possible rather than to promote logstash specifically. 😅 I don't currently have a preference, but it seems like it would be good to try to be open with whatever info is collected.
Sounds good! I've also seen some use of ClickHouse recently for collecting RUM data. And here's a marketing page for the logging use case: It might be something to consider as well. Whatever we choose will likely be better than Slack :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I left one question that could be addressed depending on your answer. :) Thanks!
@@ -159,6 +160,8 @@ function Modals(blueprint: Blueprint) { | |||
useEffect(() => { | |||
addCrashListener(logger, (e) => { | |||
const error = e as CustomEvent; | |||
logErrorEvent(error.detail?.source); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-rhetorical question:
It looks like this will log a generic error if error.detail
is not defined. Do we want that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a custom event we create, so detail.source
should always be available, but let's be safe.
I added a check for the source
in ad63c49
if (error.detail?.source) { | ||
logErrorEvent(error.detail.source); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While testing this I realized that request errors show only a white screen without any error messages.
I think that we can improve this, so I opened an issue #1993
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to also log errors when the source
is empty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From reading the code this shouldn't happen, but let's track it to make sure it stays like that. a10dfc9
logTrackingEvent('step', { step: step.step }); | ||
|
||
if (step.step === 'installPlugin' && (step as any).pluginData.slug) { | ||
logTrackingEvent('install', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the advantage of having a single install
event with either a plugin
or theme
prop vs having separate installPlugin
and installTheme
events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None, it will probably be easier to build reports with separate events.
I switched to two events beeb585
The structure looks really good. I left a few tactical questions. |
This PR will track which plugins and themes were installed during boot from a Blueprint, by sending a
installTheme
andinstallPlugin
events.An
error
event will be sent if Playground experiences a boot or PHP request error.All events are sent to Google Analytics and don't contain any personal data information.
InstallTheme
andInstallPlugin
events will only include the theme/plugin slug.Error
events will only send an errorsource
which can be:bootSiteClient
- error occurred during boot.php-wasm
- internal PHP.wasm error occurred during a PHP request.request
- a PHP or SQL error occurred during a PHP request.unknown
- for request errors that don't have a source. This shouldn't happen but we still want to catch it to confirm it's not happening in practice.The purpose of the
error
event is to provide insights into how frequently users experience issues.It's not intended for logging or debugging.
Fixes #1778
Testing Instructions (or ideally a Blueprint)
console.log
before this linewordpress-playground/packages/playground/website/src/lib/tracking.ts
Line 26 in acea593
instappPlugin
andinstallTheme
install event were sentbootSiteClient
error was sentrequest
error was sent