"Ends with" Constraint

[Anonymous]

In his (excellent) summit session "Under the Hood II: Tuning Batch Campaign Performance", Scott Nash recommended using an "ends with" constraint when filtering on Email Address where contains "@<email domain>" doesn't do the job because of subdomains (and where you don't want Marketo searching through zillions of emails as it would have to do with "contains <email domain>" without the "@" symbol. At the time I thought this constraint must have been added without my noticing and - to be honest - was embarrassed to have missed such a useful addition. However, there is no such constraint available in either of the Marketo instances I currently have access to. Has anyone seen this? Is it a secret feature you have to ask for?

Justin Cooperman​ - Can you shed any light on this?

[Devraj_Grewal]

Denise,

I am not aware of a workaround but I know there is at least an idea: or

[Anonymous]

Hi Devraj,

Yeah - I'm aware of that idea, too. The odd thing was the Marketo's VP Product Platform recommended the use of that filter constraint in his presentation. I wish I had asked him about it after the session but given his position I assumed I was wrong in thinking it didn't exist.

Denise

[SanfordWhiteman]

The usual workaround I use (other than calling a webhook, whiich I know you also have access to) is to have a separate field -- maintained via Change Data Value -- that always contains the {{Lead.Email Address}} followed by a $. Then use

Contains "@example.com$" or Contains ".example.com$"

A related technical note: with a standard SQL database "ends with" isn't significantly faster than "contains" on such small strings. The only thing that would make it faster is a separate field or index that includes only the domain part (that could then be searched via an exact case-insensitive match).

[Anonymous]

Thank you, Sandy! I wouldn't have thought of that. In the one case where "ends with" would be useful (though sounds like it wouldn't solve the processing time issue) is where we are trying to capture all the email addresses that end with ibm.com. With these that solution would work because the email are like this: @uk.ibm.com, @de.ibm.com, etc.

[Anonymous]

Denise,

Thanks for following up. I'd based that on a conversation I'd had with an engineer, but let me double-check it.  I know there is at least one other way to do a comparison, but I'm not sure it's scalable or officially supported. 

Give me a couple of days to follow up with the search engineer.  The only way to curb multi-contains usage (short of disabling it altogether) is to provide a reasonable alternative.  Disabling it would be throwing the baby out with the bathwater, which is something I'd like to avoid at all costs.  The answer might end up being using the @ symbol and listing out subdomains.  Let me see.

Scott

[Anonymous]

Hi Scott,

Thank you very much for the (fast) reply. This doesn't seem to be causing us any problem but we are using this filter in a Smart List "contains: ibm.com" because we can't predict all the country abbreviations that come after the @ symbol but precede "ibm.com." My main issue was confusion as to the existence of the constraint.

Best,

Denise

[Anonymous]

One contain item is not a problem.  It's the customers that put HUNDREDS of those in.  That's what blows up Corona.

"Contains: ibm.com" isn't perfect though.  While it might work for companies savvy enough to have one central domain, it won't work if they have ibm.co.jp also.  That's the type of stuff ABM is designed to deal with.

Sanford is right about Ends with not being faster - see my follow-on reply summarizing my discussions with the Corona architect.

Sanford, your syntax on the subdomain contains is interesting.  I recognize it from the regex work I've been doing with Splunk.  I'll ask the architect if that's a viable approach.

[Anonymous]

43fcb2b18e5e06a2f0872799aadb6bee09ffcf1b wrote:

I'll ask the architect if that's a viable approach.

By which I mean "if that's a viable approach at high volume."

[SanfordWhiteman]

Sanford, your syntax on the subdomain contains is interesting. I recognize it from the regex work I've been doing with Splunk. I'll ask the architect if that's a viable approach.

It's really just using regex-like syntax because that's easily recognizable. And has the advantage that a literal $ can't ever be the last character in a (publicly routable) email address, so it can be used for this purpose.