SOLVED
1 ACCEPTED SOLUTION
Accepted Solutions
don't include the https:// , unlike if you use "web page: starts with."
No, the [Starts With] constraint does not use the protocol, either.
As I explained above, in Marketo filters, the "Web Page" is composed of the host + pathname + hash components. It does not contain the protocol (nor the two slashes after the protocol) nor search/query string.
In case you aren't familiar with these components, every absolute URL is composed of 5 principal text components[1] and a few static delimiter characters which glue other components together.
- The scheme, "http" or "https". When paired with a following colon ":" it's known as the protocol. Neither the scheme nor the protocol includes the 2 slashes "//" afterward, which is a delimiter (so technically a separate URL component).
- The authority, which is typically the DNS name of the server, such as www.example.com or www.example.co.uk. The plain DNS name is also known as a hostname. When web servers run on anything other than the standard port for either http or https (the standards are 80 and 443, respectively) the authority must be expressed as a host (rather than merely hostname), which is the hostname plus a colon ":" and a number; when the standard ports are used, the host and hostname are the same. For example, in the URL https://www.example.com, the authority, hostname, and hostname are all "www.example.com". While in the URL https://www.example.com:8383, the authority is "www.example.com:8383"; the hostname is "www.example.com"; and host is "www.example.com:8383". Note the authority/host/hostname do not include the "/", "?", or "#" that may come afterward: those characters are considered either to belong to other components or be their own components.
- The optional pathname, which starts with (and includes) the first "/" character[2] after the authority and ends with (but does not include) the first "?" or "#" character, or goes through the end of the URL if there are no "?" or "#". In the URL https://www.example.com/folders/are/fun/as/are/files.html?some-search-terms=apples#section1, the pathname is "/folders/are/fun/as/are/files.html".
- The optional search, which starts with (and includes) the first "?" after the pathname and ends with (but does not include) the first "#" character, or goes through the end of the URL if there's no "#". In common parlance the query string is considered interchangeable with the search, although they are different in a small but significant way. The query (per the general URI standard) doesn't include the "?" character, which is considered a delimiter; the search (per the HTTP-specific URL standard) does include the "?". It's basically impossible to know which interpretation a given platform uses without testing!
- The optional hash, which starts with (and includes) the first "#" after the search and ends at the end of the URL. As with search vs. query, there's a near-but-not-quite-synonym in the URI standard: the fragment is the text after the "#" symbol but doesn't include the "#" itself. Like search and query, fragment and hash are used interchangeably in conversation, but are technically different. This ambiguity can be frustrating when communicating between business and technical folks, because "the hash" or "hashtag" might mean mean hash.substring(1) (cutting off the delimiter) or perhaps the full value of the hash.
A couple of other notes:
- Marketo uses case-insensitive Web Page searches, which is incorrect (but admittedly unlikely to be fixed). With the exception of the host -- as DNS names are always case-insensitive -- URLs are definitely case-sensitive! The URL https://codepen.io/figureone/pen/ENxBNd brings up one of my Pens, while https://codepen.io/figureone/pen/ENxBND is a 404. Luckily, though this was broken for awhile, the {{Trigger.Web Page}} token preserves the case of the URL, so you can pass it to a webhook, or read the logs via API, for full accuracy.[3]
- Although it's extraordinarily unlikely to cause a problem, leaving the protocol out of the Web Page is also not right. The secure and insecure version of a site do not have to point to the same pages: two URLs that differ only by the protocol can show totally different content. For sanity's sake, most sites serve the same content on http://example.net and https://example.net, but it's not necessary to do so.
- The "Webpage URL" value in the Activity Log Details pane adds more confusion, because it doesn't include the host, but only the pathname + hash!
[1] I've borrowed from and simplified two different standards here (the generic URI standard and the HTTP-specific URL standard) to get the different terms across for a general-ish audience.
[2] Note Internet Explorer does not correctly parse pathnames according to the standard, as it doesn't include the starting "/" (i.e. it incorrectly considers the "/" to be a separate character). This can cause some nasty problems in JavaScript.
[3] Not every webserver bothers to do a case-sensitive match on incoming URLs. That doesn't mean URLs aren't case-sensitive, as proven on millions of sites. You can't guess that a given site ignores case, it has to be specifically tested.
don't include the https:// , unlike if you use "web page: starts with."
No, the [Starts With] constraint does not use the protocol, either.
As I explained above, in Marketo filters, the "Web Page" is composed of the host + pathname + hash components. It does not contain the protocol (nor the two slashes after the protocol) nor search/query string.
In case you aren't familiar with these components, every absolute URL is composed of 5 principal text components[1] and a few static delimiter characters which glue other components together.
- The scheme, "http" or "https". When paired with a following colon ":" it's known as the protocol. Neither the scheme nor the protocol includes the 2 slashes "//" afterward, which is a delimiter (so technically a separate URL component).
- The authority, which is typically the DNS name of the server, such as www.example.com or www.example.co.uk. The plain DNS name is also known as a hostname. When web servers run on anything other than the standard port for either http or https (the standards are 80 and 443, respectively) the authority must be expressed as a host (rather than merely hostname), which is the hostname plus a colon ":" and a number; when the standard ports are used, the host and hostname are the same. For example, in the URL https://www.example.com, the authority, hostname, and hostname are all "www.example.com". While in the URL https://www.example.com:8383, the authority is "www.example.com:8383"; the hostname is "www.example.com"; and host is "www.example.com:8383". Note the authority/host/hostname do not include the "/", "?", or "#" that may come afterward: those characters are considered either to belong to other components or be their own components.
- The optional pathname, which starts with (and includes) the first "/" character[2] after the authority and ends with (but does not include) the first "?" or "#" character, or goes through the end of the URL if there are no "?" or "#". In the URL https://www.example.com/folders/are/fun/as/are/files.html?some-search-terms=apples#section1, the pathname is "/folders/are/fun/as/are/files.html".
- The optional search, which starts with (and includes) the first "?" after the pathname and ends with (but does not include) the first "#" character, or goes through the end of the URL if there's no "#". In common parlance the query string is considered interchangeable with the search, although they are different in a small but significant way. The query (per the general URI standard) doesn't include the "?" character, which is considered a delimiter; the search (per the HTTP-specific URL standard) does include the "?". It's basically impossible to know which interpretation a given platform uses without testing!
- The optional hash, which starts with (and includes) the first "#" after the search and ends at the end of the URL. As with search vs. query, there's a near-but-not-quite-synonym in the URI standard: the fragment is the text after the "#" symbol but doesn't include the "#" itself. Like search and query, fragment and hash are used interchangeably in conversation, but are technically different. This ambiguity can be frustrating when communicating between business and technical folks, because "the hash" or "hashtag" might mean mean hash.substring(1) (cutting off the delimiter) or perhaps the full value of the hash.
A couple of other notes:
- Marketo uses case-insensitive Web Page searches, which is incorrect (but admittedly unlikely to be fixed). With the exception of the host -- as DNS names are always case-insensitive -- URLs are definitely case-sensitive! The URL https://codepen.io/figureone/pen/ENxBNd brings up one of my Pens, while https://codepen.io/figureone/pen/ENxBND is a 404. Luckily, though this was broken for awhile, the {{Trigger.Web Page}} token preserves the case of the URL, so you can pass it to a webhook, or read the logs via API, for full accuracy.[3]
- Although it's extraordinarily unlikely to cause a problem, leaving the protocol out of the Web Page is also not right. The secure and insecure version of a site do not have to point to the same pages: two URLs that differ only by the protocol can show totally different content. For sanity's sake, most sites serve the same content on http://example.net and https://example.net, but it's not necessary to do so.
- The "Webpage URL" value in the Activity Log Details pane adds more confusion, because it doesn't include the host, but only the pathname + hash!
[1] I've borrowed from and simplified two different standards here (the generic URI standard and the HTTP-specific URL standard) to get the different terms across for a general-ish audience.
[2] Note Internet Explorer does not correctly parse pathnames according to the standard, as it doesn't include the starting "/" (i.e. it incorrectly considers the "/" to be a separate character). This can cause some nasty problems in JavaScript.
[3] Not every webserver bothers to do a case-sensitive match on incoming URLs. That doesn't mean URLs aren't case-sensitive, as proven on millions of sites. You can't guess that a given site ignores case, it has to be specifically tested.
.png)