Skip to main content
Solved

Using "null" in a condition

  • November 13, 2024
  • 5 replies
  • 142 views
divinetomedy

Hi there,

I’m not sure how to handle NULL values in my incoming event data. Specifically, I want a conditional true/false branch based on whether an event attribute’s value is NULL, or whether it’s populated (it’s normally a epoch timestamp, so, an int I think). It’s the “crossed_at” attribute here:

 

 

And here are my options for the conditional branch:

 

For “does not exist”, will that include attributes that technically DO exist but have a value NULL? I wish there were one that said “is null”. Even better would be to have that one PLUS “is blank”, which would indicate “either missing or null or empty string”, which is super handy.

Anyway, does anyone know how to definitively branch on NULL? I could experiment with a bunch of these, but thought I’d check with the community (cough...Felix...cough :) first.

Thanks,
TOM

 

Best answer by divinetomedy

Felix - as always, such a great response - thank you! Ok, to summarize (for my own sanity, and for anyone reading this in the future):

It sounds like CIO treats null (nil) and empty string as the same thing, and discourages sending either (i.e. you should just not send the property at all, not least because they can’t be saved as a user property). But if you do send either, it will register as TRUE for the “does exist” condition.

FYI, sometimes my devs are just sending a full object’s properties/attributes in a payload, which sometimes includes null values, so it’s actually harder for them to omit sending some. That’s a bummer, because I can’t use “does not exist” reliably, since that will register TRUE for null values, I believe.

Feature request: could we get a new conditional that nicely handles these? I’ve seen “is blank” (instead of just “does not exist”) – it could even be more explicit, like “is blank, empty, or doesn’t exist” – which would register TRUE for either null/nil, empty string, or completely omitted properties. That would be super handy, and would work for non-string values as well.

View original
Did this topic help you find an answer to your question?

5 replies

Felix
  • Felix
  • Novice
  • 223 replies
  • November 14, 2024

Hey Tom,

now I have to answer this 😀 No way around it!

 

I checked and the documentation regarding attributes states the following:

Setting an attribute value to an empty string or null is the same as removing that attribute from a person.

 

This seems to be the case for events as well. I sent myself an event (btw a really nice feature for testing) and created a segment. Choosing “does not exist” outups one person, whereas choosing “is equal null” outputs 0. CIO seems to simply ignore the null attributes.

 

PS: According to CIO the best practice would be to not pass over null values or empty strings (see docs)

 

Hope that helps,

Felix

More questions? Shoot me a message by clicking on my name. We are a certified customer.io agency. Happy to help!
divinetomedy
1 person likes this
  • divinetomedy
    divinetomedy
divinetomedy
  • divinetomedy
  • Author
  • Scholar
  • 17 replies
  • Answer
  • November 14, 2024

Felix - as always, such a great response - thank you! Ok, to summarize (for my own sanity, and for anyone reading this in the future):

It sounds like CIO treats null (nil) and empty string as the same thing, and discourages sending either (i.e. you should just not send the property at all, not least because they can’t be saved as a user property). But if you do send either, it will register as TRUE for the “does exist” condition.

FYI, sometimes my devs are just sending a full object’s properties/attributes in a payload, which sometimes includes null values, so it’s actually harder for them to omit sending some. That’s a bummer, because I can’t use “does not exist” reliably, since that will register TRUE for null values, I believe.

Feature request: could we get a new conditional that nicely handles these? I’ve seen “is blank” (instead of just “does not exist”) – it could even be more explicit, like “is blank, empty, or doesn’t exist” – which would register TRUE for either null/nil, empty string, or completely omitted properties. That would be super handy, and would work for non-string values as well.

divinetomedy
  • divinetomedy
  • Author
  • Scholar
  • 17 replies
  • November 14, 2024

Btw, I’m going to flag my own response as “Best answer” because it distills everything. I’m a little embarrassed to do that but hopefully it’s easier for people to find in the future (and hopefully doesn’t impact your amazing response stats, Felix!!).

Felix
1 person likes this
  • Felix
    Felix
Felix
  • Felix
  • Novice
  • 223 replies
  • November 15, 2024

Don't be! It's a really good summary 😁

 

Tagging ​@Ryan_cio and ​@Customer.io regarding the feature request 😉

More questions? Shoot me a message by clicking on my name. We are a certified customer.io agency. Happy to help!
Ryan_cio
  • Ryan_cio
  • 49 replies
  • November 19, 2024

Hi ​@Felix & ​@divinetomedy,

Thanks for the tag here! I’ve gone ahead and tracked this feature request for you to allow to both set null and handle these better in conditions.

Let me know if there is any other context that I can include here for our team :)

Have a great rest of your week!

- Ryan
divinetomedy
1 person likes this
  • divinetomedy
    divinetomedy

Reply


Most helpful members this week

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
Product
Resources
Industry
Company

Privacy PolicyTerms of ServiceStatus© Peaberry Software, Inc.

Terms & ConditionsCookie settings