Hi Team, we have an Enterprise customer who using the Kotlin and Java SDK and has noticed that the same user is being bucketed in different variations on each SDK when maintaining a consistent growthbook_id identifier on each. They have asked if there is a way to ensure parity and how the hashing works for each SDK. Please, can you review their testing results (below) and confirm if there is a solution for this? We also had something similar mentioned in the #C05T9EY0UKC channel here, where this PR was released for it, is it the same thing happening in Kotlin perhaps? Customer testing: I’ve recently integrated the GrowthBook Java SDK (v 0.9.91) into our Android app and ran some tests to compare its behavior with the current Android/Kotlin SDK (v 1.1.41) implementation. I noticed a discrepancy in how the two SDKs bucket the same user, even when using identical attributes. TL;DR: The same user, identified by the

growthbook_id

, is being assigned to different variations by the two SDKs. After initializing both SDKs, I set up the same attributes and captured the

ExperimentResult

logs. Here’s a representative comparison: Android SDK (current implementation):

Experiment ab-app-multiple__double-points result: {"id":"doublePoints","enabled":true,"configuration":{...}}
hashAttribute: growthbook_id -> 7662e35d-57a9-49bd-a0b6-db2268ad0439  
bucket: -> null  
variationId: -> 1

J*ava SDK (our new integration):*

Experiment ab-app-multiple__double-points result: {id=doublePoints, enabled=false}  
hashAttribute: growthbook_id -> 7662e35d-57a9-49bd-a0b6-db2268ad0439  
bucket: -> 0.4606  
variationId: -> 0

Both SDKs correctly pick up the same

growthbook_id

, but produce different bucketing outcomes: • The Android SDK consistently returns

null

for the bucket but assigns the user to variation

1

(variant). • The Java SDK returns a valid bucket (

0.4606

) and assigns the user to variation

0

(control). These tests were performed on the same device, without using any proxy or intermediate layer—just a direct call to GrowthBook apiHost with the same apiKey. This suggests a potential inconsistency in how the SDKs compute the hash/bucket based on the provided attribute. To further investigate, I tested other

growthbook_id

values and observed inconsistent results: • `7662e35d-57a9-49bd-a0b6-db2268ad0439`: Android SDK → variant, Java SDK → control • `1a2f94b5-667e-4a7d-9823-8d4bf611085c`: Android SDK → control, Java SDK → variant • `23aa8888-97fe-4c57-9a57-f3517fa1f89c`: Android SDK → variant, Java SDK → control • `3145ff6a-2148-48cb-b032-7f1892380a17`: Android SDK → variant, Java SDK → control • `07b18ce4-6311-42ae-9bd9-68cd5e2623fc`: Android SDK → variant, Java SDK → variant Given that the same inputs yield different results, this seems like something internal to how each SDK handles hashing and bucketing. Do you happen to know if there’s a known difference in hashing logic between the Java and Android SDKs? Or is there a recommended way to ensure parity? Any insights or suggestions on how to approach this would be greatly appreciated!

Hi @flaky-noon-11399. Please let us check that and we will write to you.

reproduced

bucket

null

variationId

1 on 1.1.41. It is planned to fix.

variationId

is already fixed in latest SDK version.

bucket

is left to fix.

Thank you

Thank you team, I'll let the customer know 🚀

I would propose to the customer at least update to v5.0.0. The customer is using v1.1.41. The changes they asked will be in new SDK version.

We will do our best to fix the second part of the issue that hasn't been resolved yet and provide a new update as soon as possible.

In v1.1.41

bucket

value is

null

. In v5.0.1

bucket

value is the same as in the Java SDK.

Hi @flaky-noon-11399 . Could you please update to the latest version and check if the issue still exists?

Thank you, I'll check in with the customer 🙏

Thank you