Amplitude measurement when using SSR.
Answered
Barbary Lion posted this in #help-forum
Barbary LionOP
We've set up Amplitude's browser SDK for our apps analytics. We currently initialize it in a context provider that wraps the whole application and this works fine for client side components. I'm trying to figure out how to call our analytics for our SSR pages as well. We're using the app router.
Currently, I'm getting a "ERROR: Ampli is not yet initialized. Have you called ampli.load() on app start?" on SSR pages. They're obviously not getting the context provider.
The options I could think of were:
1) Also implement the Amplitude Node SDK - It's not clear to me if you can have two Amplitude SDKs operating in tandem and where we would initialize the Node SDK in this scenario.
2) Create client side components as children of SSR pages. These components would only call Amplitude page view events.
3) Rework how we're passing our Amplitude context throughout the application. I have not figured out where I'd start on this.
An ideal solution would use a single Amplitude SDK and enable calls from the browser and SSR pages.
Currently, I'm getting a "ERROR: Ampli is not yet initialized. Have you called ampli.load() on app start?" on SSR pages. They're obviously not getting the context provider.
The options I could think of were:
1) Also implement the Amplitude Node SDK - It's not clear to me if you can have two Amplitude SDKs operating in tandem and where we would initialize the Node SDK in this scenario.
2) Create client side components as children of SSR pages. These components would only call Amplitude page view events.
3) Rework how we're passing our Amplitude context throughout the application. I have not figured out where I'd start on this.
An ideal solution would use a single Amplitude SDK and enable calls from the browser and SSR pages.
Answered by Barbary Lion
In case anyone has the same issue, here's what we settled on:
1) Only implement the Amplitude Browser SDK and Ampli wrapper
2) create page specific components with the 'use client'; declaration.
3) within those components, only include the relevant analytics code within a useEffect() hook to control when it fires and return null.
The one drawback is that analytics events can only correspond to user visible changes in the application. We won't be able to fire off an event that happens server side if there isn't any state change that's visible to the user's browser.
1) Only implement the Amplitude Browser SDK and Ampli wrapper
2) create page specific components with the 'use client'; declaration.
3) within those components, only include the relevant analytics code within a useEffect() hook to control when it fires and return null.
The one drawback is that analytics events can only correspond to user visible changes in the application. We won't be able to fire off an event that happens server side if there isn't any state change that's visible to the user's browser.
1 Reply
Barbary LionOP
In case anyone has the same issue, here's what we settled on:
1) Only implement the Amplitude Browser SDK and Ampli wrapper
2) create page specific components with the 'use client'; declaration.
3) within those components, only include the relevant analytics code within a useEffect() hook to control when it fires and return null.
The one drawback is that analytics events can only correspond to user visible changes in the application. We won't be able to fire off an event that happens server side if there isn't any state change that's visible to the user's browser.
1) Only implement the Amplitude Browser SDK and Ampli wrapper
2) create page specific components with the 'use client'; declaration.
3) within those components, only include the relevant analytics code within a useEffect() hook to control when it fires and return null.
The one drawback is that analytics events can only correspond to user visible changes in the application. We won't be able to fire off an event that happens server side if there isn't any state change that's visible to the user's browser.
Answer