Actions Amplitude Integration Object Malformed When Combined With Session ID

[RichJacobs69]

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.

[edsonjab]

Hi @RichJacobs69 thank you for your report, we start looking into this.

[edsonjab]

HI @RichJacobs69 I tried replicate your scenario, but I don't have success
could you help me to share your implementation please?

If is possible include which versions of frameworks are you using please.

[caprica]

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:

• v5.7.0 of this library
• v18.2.0 of React
• v13.0.1 of NextJS

...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):

// Version of the Segment Analytics snippet to load
const SNIPPET_VERSION = '4.15.12';

// Production Segment ID
const SEGMENT_ID = config().segmentWriteKey;

// Segment initialisation code, injected as a script
//
//  - note we do NOT invoke page() here, unlike the default script
//  - note we do NOT invoke analytics.load(writeKey) as the consent manager manages the loading of analytics
export const SEGMENT_HTML = `!function(){var analytics=window.analytics=window.analytics||[];if(!analytics.initialize)if(analytics.invoked)window.console&&console.error&&console.error("Segment snippet included twice.");else{analytics.invoked=!0;analytics.methods=["trackSubmit","trackClick","trackLink","trackForm","pageview","identify","reset","group","track","ready","alias","debug","page","once","off","on","addSourceMiddleware","addIntegrationMiddleware","setAnonymousId","addDestinationMiddleware"];analytics.factory=function(e){return function(){var t=Array.prototype.slice.call(arguments);t.unshift(e);analytics.push(t);return analytics}};for(var e=0;e<analytics.methods.length;e++){var key=analytics.methods[e];analytics[key]=analytics.factory(key)}analytics.load=function(key,e){var t=document.createElement("script");t.type="text/javascript";t.async=!0;t.src=https://cdn.segment.com/analytics.js/v1/ + key + "/analytics.min.js";var n=document.getElementsByTagName("script")[0];n.parentNode.insertBefore(t,n);analytics._loadOptions=e};
analytics._writeKey="${SEGMENT_ID}";;
analytics.SNIPPET_VERSION="${SNIPPET_VERSION}";
}}();`;

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
      }}
    />
  );

[caprica]

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?

[edsonjab]

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.

[caprica]

According to Segment support, there is a known issue in their JIRA on this topic.

"an active JIRA ticket that mentions consent manager causing issues with some destinations like Amplitude. In summary the core of the issue is due to how Amplitude's value in the Integration object is an object, rather than a boolean"

And that's all we have to go on with no indication of any fix forthcoming /shrugs.

[caprica]

With consent manager removed, we still see this in our Segment debugger:

"integrations": {
  "Actions Amplitude": {
    "session_id": 123123123123
  }
}

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?

[caprica]

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.

[edsonjab]

@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.

[samuelhorn]

@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:

"integrations": {
  "Actions Amplitude": {
    "session_id": 123123123123
  }
}

instead of:

"integrations": {
  "Actions Amplitude": true
}

I tried manually to change the source of Consent Manager to what @bobbyatsegment did here. While that works, you have to manually submit the analytics_session_id on all events which is not ideal.

[leethree]

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 { session_id } object should be considered "truthy" when Segment tries to process it?

[noah-potter]

We did get an response about this from Segment support, but it's similar to what was said in January:

According to Segment support, there is a known issue in their JIRA on this topic.

"an active JIRA ticket that mentions consent manager causing issues with some destinations like Amplitude. In summary the core of the issue is due to how Amplitude's value in the Integration object is an object, rather than a boolean"

And that's all we have to go on with no indication of any fix forthcoming /shrugs.

Here's what we were told:

08/31/2023
I have looked into some of the JIRAs and conversations regarding this issue, and it seems there are many concerns regarding current expected behaviors and how that could impact customers if a change is made. That said, I have revived the conversation and am hopeful the engineers can shed more light on whether there is an intention to provide a fix for this.

I certainly understand that the current workaround of forcing 'All': true is not ideal, particularly if there are multiple destinations involved.

I will place this ticket on hold on my end to prevent it from auto-closing, and provide you with updates when I hear more from engineering.

09/06/2023
After reaching out to engineering on this, they have let me know that they are blocked on the project for the time being. However, it is still in the backlog to be worked on. Unfortunately, I cannot provide an ETA on this at this time.

Our destination setup is still quite simple, so we're just adding All: true to every request using middleware (essentially this workaround #349), but if our setup becomes more complex, we'll probably be looking at the workaround here: #307

[ravenwilde]

Any movement on this? We're unable to upgrade to Amplitude (Actions) due to this issue.