Hi all,
We wish to create our own traffic and conversion language (if you would call it that). To do this we wanted to create filtering criteria based on drill-down 2 properties. However we came to notice that the values behind this property don’t work with special filter criteria (because computers dont read the string directly on drill-down 2 but rather a number ID) so we can’t have a filter saying “Latest Traffic Source Drill-down 2 contains any of X, Y, or Z” we can only use exact values.
Any ideas or ways to work around this?
Hi @galvanA81,
To get the IDs behind the human-readable label, simply hover your mouse here on a contact you know was created by that source:
You can then grab the ID and filter for it. And yes, you would have to repeat this for every source that behaves like this.
Best regards!
yeah, that im aware of. Maybe I explain a little better. We want to have our translations/values based on the values behind drill-down 2.
So in our workflow we have a branch that branches based on the following criteria:
But from what we have experienced, filtering like this will not work for drill-down 2. We cant use exact values because the idea was to “catch” anything related to an event/tradefair. And we cant use drill-down 1 because the value for these cases is “IMPORT” which is too generic for us.
Hi @galvanA81
From what I’ve seen, the drill-down properties can be a bit limiting because they’re stored as internal values rather than plain text, which is why operators like contains any of aren’t available.
If you need to group multiple drill-down values under your own traffic categories, I’d probably create a custom property (for example, “Traffic Category”) and use a workflow to map each exact drill-down value to the category you want. You could then build your lists, reports, and filters against that custom property instead of the drill-down field.
I haven’t seen a native way to use partial text matching on the drill-down properties themselves, but I’d be interested to hear if anyone has found a different approach.
Hi @galvanA81, Yeah, that’s expected behavior drill down properties store an internal ID mapped to the string, not the raw text, which is why “contains” logic breaks. A common workaround: create a custom property (single-line text or dropdown) and use a workflow to copy the actual Drill-down 2 value into it as a readable string whenever it’s set/updated then build your “contains any of X, Y, Z” filter against that custom property instead. It adds a bit of workflow overhead, but it’s the standard way people get around the ID-vs-string limitation on default traffic analytics properties.
Hi @Emmytech and @TeeTech , drill-down 1 works fine, issue is with drill-down2, doing the “Edit record” workflow action to this property will still copy the internal value into my custome property.
Hi @That makes sense if the workflow is copying the internal value instead of the displayed drill-down 2 label, then the issue is with how HubSpot stores that property rather than the workflow action itself.
In that case, a simple “Edit record” action probably won’t solve it. You may need a step that translates the internal IDs into your own readable values (for example, using custom mapping logic or a custom property that is populated based on those values).
I haven’t tested every possible workaround for drill-down 2 specifically, but it sounds like the limitation is coming from the property type rather than the automation.
Curious if anyone has found a native way to reference the display value of drill-down 2 instead of the internal value?
