-
Notifications
You must be signed in to change notification settings - Fork 141
Actions Amplitude Integration Object Malformed When Combined With Session ID #296
Comments
Hi @RichJacobs69 thank you for your report, we start looking into this. |
HI @RichJacobs69 I tried replicate your scenario, but I don't have success If is possible include which versions of frameworks are you using please. |
This issue is triggered just following the example code, I can only post a fragment: import React from 'react';
import { ConsentManager } from '@segment/consent-manager';
const initialPreferences = {
functional: true,
marketingAndAnalytics: true,
advertising: false,
};
export default function CookieDialog() {
return (
<ConsentManager
writeKey={config().segmentWriteKey}
bannerContent={<BannerContent />}
bannerActionsBlock={BannerActionsBlock}
bannerSubContent={bannerSubContent}
initialPreferences={initialPreferences}
preferencesDialogTitle={<PreferencesDialogTitle />}
preferencesDialogContent={<PreferencesDialogContent />}
cancelDialogTitle={<CancelDialogTitle />}
cancelDialogContent={<CancelDialogContent />}
bannerAsModal={false}
bannerHideCloseButton={true}
shouldRequireConsent={() => true}
/>
);
} All of the properties here are just standard React visual components, there is no code in them. As I understand this library, we are not in control of the payload JSON that is being sent, it is all generated inside the library. As @RichJacobs69 explains, we used to see this: {
"integrations": { "Actions Amplitude": true, "Actions Google Analytic 4": true, "All": false, "Braze Web Mode (Actions)": true, "Google Analytics": true, "Mouseflow": true, "Segment.io": true }
} But now we see this: "integrations": { "Actions Amplitude": { "session_id": 1671269658094 }, "All": false, "Braze Web Mode (Actions)": true, "Google Analytics": true, "Mouseflow": true, "Segment.io": true, "Zendesk": true i.e. it is not simply passing "true" for Amplitude, it is passing an object containing a session id. Again, we do not construct that payload, out understanding is that this library does that. We are using:
...and the following snippet to load analytics - this was originally copied from the Segment documentation with a very small change (we do not want the initial page load tracked here):
And finally we use the above snippet like this in a top-level React component: return (
<Script
id="segment-analytics"
dangerouslySetInnerHTML={{
__html: SEGMENT_HTML, // <-- snippet from above
}}
/>
); |
It's not really clear to me what's going on, I debugged this live in VS Code, and I could see it looked mostly OK, I could see e.g. true/false values and not Amplitude session ID in the Javascript objects. Yet, when the identify call is made after accepting the consent manager dialog, presumably this is now inside Segment's analytics.js?, the payload gets switched as per @RichJacobs69 original report so instead of true it sends the session id. Maybe I'm wrong, but if this is happening inside Segment analytics.js what can we do? |
Hi @caprica and @RichJacobs69 I tried replicate your issue, but I don't have success This image show how we assigned a Boolean value for every destination on consent-manager On analytics.js process the message sent from every application. |
According to Segment support, there is a known issue in their JIRA on this topic.
And that's all we have to go on with no indication of any fix forthcoming /shrugs. |
With consent manager removed, we still see this in our Segment debugger:
Obviously without taking into account consent our messages now do make to Amplitude. But I suppose this shows that Consent Manager is not doing anything wrong at this point at least? |
What we now think may be happening is this... It seems that Consent Manager is adding "all: false" to the integrations object, and then overrides each specific integration with a true/false value according to what the user has consented to. When Segment's analytics.js takes over, it sees the Amplitude integration and effectively replaces the "true" with an object containing the session id. Segment then sees "all=false", but now does not see "actions amplitude=true", because it is no longer a boolean. Therefore Segment thinks Amplitude is not enabled and does not deliver the events. So can we prevent all=false being set? If we're wrong in the above analysis we have nowhere else to go and will regrettably replace our implementation. |
@caprica thanks for your comment, sorry for the delay but I can't replicate the issue, I will check the new scenario that you propose. You can set values with the property initialPreferences. |
@edsonjab any news on this one. It's currently blocking us from replacing Google Tag Manager with Segment, since we cant get the events trough to Amplitude because of:
instead of:
I tried manually to change the source of Consent Manager to what @bobbyatsegment did here. While that works, you have to manually submit the |
We are seeing the same issue with Consent Manager adding "all=false" so the integration with Amplitude fails. One thing I don't understand is that the |
We did get an response about this from Segment support, but it's similar to what was said in January:
Here's what we were told:
Our destination setup is still quite simple, so we're just adding |
Any movement on this? We're unable to upgrade to Amplitude (Actions) due to this issue. |
We've encountered this issue as of the 13th Dec. When Consent Manager attempts to pass a boolean in the destination object for Actions Amplitude it is being malformed with the Amplitude session id plugin that is bundled with Analytics.js 2.0. The impact is that no events are being sent to our Amplitude destination
Here's how the object looked previously:
"integrations": { "Actions Amplitude": true, "Actions Google Analytic 4": true, "All": false, "Braze Web Mode (Actions)": true, "Google Analytics": true, "Mouseflow": true, "Segment.io": true }
And here's how it is now being passed:
"integrations": { "Actions Amplitude": { "session_id": 1671269658094 }, "All": false, "Braze Web Mode (Actions)": true, "Google Analytics": true, "Mouseflow": true, "Segment.io": true, "Zendesk": true
Has anyone else encountered this? Did you have any luck correcting it short of reverting back to analytics.js 1.0? We're not sure if it's possible to suppress the plugin or force it into another part of the payload e.g. context.
The text was updated successfully, but these errors were encountered: