Active session recordings should respect changes in config.disable_persistence

[bhamiltoncx]

Here's where SessionRecording is instantiated. It reads config.disable_persistence only once at init time:

mixpanel-js/src/recorder/session-recording.js

Lines 107 to 119 in c23600f

	var usePersistence = localStorageSupported(options.sharedLockStorage, true) && !this.getConfig('disable_persistence');
	// each replay has its own batcher key to avoid conflicts between rrweb events of different recordings
	this.batcherKey = '__mprec_' + this.getConfig('name') + '_' + this.getConfig('token') + '_' + this.replayId;
	this.queueStorage = new IDBStorageWrapper(RECORDING_EVENTS_STORE_NAME);
	this.batcher = new RequestBatcher(this.batcherKey, {
	errorReporter: this.reportError.bind(this),
	flushOnlyOnInterval: true,
	libConfig: RECORDER_BATCHER_LIB_CONFIG,
	sendRequestFunc: this.flushEventsWithOptOut.bind(this),
	queueStorage: this.queueStorage,
	sharedLockStorage: options.sharedLockStorage,
	usePersistence: usePersistence,

It's instantiated here when startRecording() is invoked:

mixpanel-js/src/recorder/recorder.js

Line 71 in c23600f

this.activeRecording = new SessionRecording(sessionRecordingOptions);

But nothing calls into active SessionRecordings when mixpanel.set_config() is called to update changes to config.disable_persistence:

mixpanel-js/src/mixpanel-core.js

Lines 1864 to 1891 in c23600f

	MixpanelLib.prototype.set_config = function(config) {
	if (_.isObject(config)) {
	_.extend(this['config'], config);
	var new_batch_size = config['batch_size'];
	if (new_batch_size) {
	_.each(this.request_batchers, function(batcher) {
	batcher.resetBatchSize();
	});
	}
	if (!this.get_config('persistence_name')) {
	this['config']['persistence_name'] = this['config']['cookie_name'];
	}
	if (!this.get_config('disable_persistence')) {
	this['config']['disable_persistence'] = this['config']['disable_cookie'];
	}
	if (this['persistence']) {
	this['persistence'].update_config(this['config']);
	}
	Config.DEBUG = Config.DEBUG || this.get_config('debug');
	if (('autocapture' in config || 'record_heatmap_data' in config) && this.autocapture) {
	this.autocapture.init();
	}
	}
	};

To correctly handle consent changes (e.g., for EU GDPR users who have to provide explicit consent), I would expect changes to config.disable_persistence to be propagated to any active SessionRecording s in flight.

[jakewski]

Hey, thanks for the report. Do the opt_in_tracking / opt_out_tracking methods not fit this use case?

Session recording would probably need a major refactor to disconnect from persistent storage while continuing the recording, so if we need to be specific about just stopping persistence the best bet now would be to stop session recording or wait for consent before starting it up.

Note that the default event / people batching also does not respect a set_config({disable_persistence: false}) call, which is backed by localStorage

[bhamiltoncx]

Do the opt_in_tracking / opt_out_tracking methods not fit this use case?

Funny that you ask!

In fact, I initially used opt_in_tracking / opt_out_tracking in the first version of mixpanel/mixpanel-gtm-template#21, but @jblifestyles commented in mixpanel/mixpanel-gtm-template#22 (comment) that it makes more sense to just disable/enable persistence for users who have not yet granted consent.

The use-case here is to handle analytics storage consent properly, especially for EU GDPR users. Such users have to explicitly grant consent, which makes Mixpanel + Google Tag Manager initialization challenging. Either we:

1. Start such users with mixpanel.init(..., {persistence_disabled: true}), then if they later opt in, enable persistence with mixpanel.set_config({persistence_disabled: false}), or

2. Start users with persistence enabled, then when we figure out they are EU GDPR users (e.g., via geolocation), later apply mixpanel.set_config({persistence_disabled: true})

In either case, session recordings in flight should obey the change in persistence and dynamically start pushing session events to browser storage after persistence_disabled transitions from true to false.

The current situation seems to be that whatever value of persistence_disabled is set at session recording initialization time is "sticky" for the lifetime of the session, which is not what the user asks for.

[bhamiltoncx]

@jakewski , do you think I should restore mixpanel/mixpanel-gtm-template#21 to use opt_in_tracking / opt_out_tracking instead of disabling/enabling persistence?

[bhamiltoncx]

I went ahead and restored mixpanel/mixpanel-gtm-template#21 to use opt_in_tracking / opt_out_tracking.

[jakewski]

Hey @bhamiltoncx - sorry this totally slipped my radar. Yes the correct approach is to use the opt_in/out functions.

[bhamiltoncx]

Hey @jakewski — this doesn't seem to resolve the core issue.

The core issue is that there appears to be no way to configure Mixpanel to not write persistent data (cookies or local storage) until the user opts in, without also disabling active session recordings.

In order to comply with EU GDPR / ePrivacy rules, we need to configure Mixpanel to initially write nothing to persistent storage in the browser, then when the user opts in, we need to later enable persistence.

With the current implementation of session recordings, this means there's no way (even for users who opt in) to get session recordings and remain compliant with EU GDPR / ePrivacy rules.

Can you let me know if I'm missing something?

[jakewski]

Hey @bhamiltoncx unfortunately there's no way currently for a recording to switch between persisted and non-persisted mid flight, you would have to start a new recording or just start the SDK with disable_persistence on and not use the persistence features.

It would be possible to support, but there's a fair amount of state being stored and recording data is sequential (each event depends on the last) - so might be a bit tricky. I'll reopen this issue since it's a valid feature request, but can't guarantee the Mixpanel team will pick this up any time soon. PRs are welcome!

[bhamiltoncx]

Thanks, that matches my understanding. It seems like start_session_recording() doesn't obey record_sessions_percent, so we have to do our own sampling.

So, to confirm, to conform to EU GDPR / ePrivacy laws with Mixpanel session recordings, every customer has to implement the following:

1. Start Mixpanel with opt_out_tracking_by_default and disable_persistence both set to true
2. If the user opts in to tracking, call opt_in_tracking(), then manually calculate whether the user is sampled in record_sessions_percent, and if so, call start_session_recording()

This means the entire session recording leading up to the opt-in event is permanently lost, which is fairly sad (even reading the user's opt-in status from cookies can take time).