10 Replies Latest reply on Aug 31, 2018 9:19 AM by Leticia DoPrado

    "Visits Web Page" Trigger

    Leticia DoPrado

      Hi,

       

      Do you guys know if the Visits Web Page trigger works the same for both Marketo Landing Pages and our own website pages? In other words, do we have to add the pages names differently on the trigger operator if its a Marketo landing page versus a webpage (Like www.google.com versus https://www.google.com)?

       

      Thanks,

      -Leticia

        • Re: "Visits Web Page" Trigger
          Balkar Singh

          For non Mkto pages which are being tacked via Munchkin, you would want to use "contains" and URL string - google.com

          Marketo LPs will appear just as they are named in Marketo.

          1 of 1 people found this helpful
          • Re: "Visits Web Page" Trigger
            Sanford Whiteman

            In Marketo, the Visits Web Page activity defines "Web Page" as the original hostname + pathname + hash, but not the protocol nor the query string.

             

            So if you see

             

              http://www.example.com/my/folder/page.html?search=223#section1

             

            in your browser's location bar, to Marketo the "Web Page" is

             

              www.example.com/my/folder/page.html#section1

             

            The query string is also stored, and can be used as a constraint, but (to my repeated frustration) is not present in the "Web Page" nor in the {{Trigger.Web Page}} token.

             

            Marketo's definition contrasts with the more intuitive (to me) meaning of "web page" which typically includes the query string but excludes the hash (since the hash is not actually sent to web servers) or would include both.  Of course there are always product-specific definitions, you just have to learn 'em.

             

            3 of 3 people found this helpful
            • Re: "Visits Web Page" Trigger
              Jeannie Wong

              They should work the same as long as your webpage has munchkin code. You can use the trigger "visits web page" if you use "web page: is" don't include the https:// , unlike if you use "web page: starts with." If the webpage has parameters such as utms you can say "web page: is any" and add constraint "querystring: contains: utm_source="

              1 of 2 people found this helpful
                • Re: "Visits Web Page" Trigger
                  Sanford Whiteman

                  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.

                   

                  1. 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).
                  2. 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.
                  3. 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".
                  4. 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!
                  5. 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.

                  2 of 2 people found this helpful