This message was deleted.
# announcements
w
This message was deleted.
f
it could be caused by the assignment attribute of the experiment being different than the assignment in the experiment report
but usually they are caused by changing of the split mid experiment
l
hi @fresh-football-47124 thanks for the quick reply. I have checked that 1. the hashed attribute did not change, 2. the experiment start time is above the last feature change i can see in the audit log. 3. split was not modified
f
what split do you have?
l
hi Graham, sorry for the late reply, it's 50/50
Copy code
{
  "defaultValue": false,
  "rules": [
    {
      "condition": {
        "deviceId": "test-forced-on"
      },
      "force": true
    },
    {
      "condition": {
        "loginStatus": 0
      },
      "variations": [
        false,
        true
      ],
      "coverage": 1,
      "weights": [
        0.5,
        0.5
      ],
      "key": "MyExptKey",
      "hashAttribute": "deviceId"
    }
  ]
}
Copy code
Warning: Sample Ratio Mismatch (SRM) detected. We expected a 50/50 split, but observed a 50.4/49.6 split (p-value = 9.2e-7). There is likely a bug in the implementation.
1. Sorry, i misunderstood your question. It's 50.4/49.6 split. 2. And i assume GB is able to calculate the split number is because of all of the queries (i currently have 10 of them) for this particular experiments 3. And i'm wondering which field is used to calculate the split number ? I can see
count, main_sum, main_sum_square
140 Views