Adding <meta> tags - stop Keytiles guessing!
On this page we try to explain the "meta" tags approach. Why is it there at all? What problems does it solve? And how does it work?
Content of this page
- # Prerequisite
- # When to add <meta> tags?
- # What are <meta> tags?
- # <meta> tags reference
- # kt:tileId
- # kt:tileType
- # kt:tileGroupPath
- # kt:tileTitle
- # kt:tileUrl
- # kt:visitorType
- # OK but what does Keytiles do then without these <meta> tags?
At this point we assume that you are already familiar with what Keytiles needs to know about a visit (aka "hit") over your content.
Please read our Hit attributes article first before you continue!
If you have a traditional "1 page - 1 content" website so we can say a content visit = a page load then you can go with the basic installation of the tracking script (see our Getting started article) then <meta> tags is exactly designed for you to carry the extra information Keytiles needs to know.
The HTML standard defines the proper placeholder for "meta" information belongs to a page (and in your case to a content) - and these are the <meta> tags one can add to the <head> section of the page.
<html> <head> ... <meta name="<the name>" content="<the value>" /> ... </head> ... </html>
With the use of Keytiles Meta Tags the website owner - the only master of his own content structure - can provide everything Keytiles needs to know.
Let us list the different tags now!
<meta name="kt:tileId" content="<the unique entity ID>">
The unique ID of this content (entity) Keytiles can use to recognize the entity (regardless the URL) and track it correctly.
This is the equivalent to tileId hit attribute - please see the details there!
<meta name="kt:tileType" content="<one of the valid types>">
The type of the content.
This is the equivalent to tileType hit attribute - please see the details there!
<meta name="kt:tileGroupPath" content="<the path where this tile belongs to in the structure>">
This is an "/a/b/c" like string - defining the path in your content structure this tile belongs to.
This is the equivalent to tileGroupPath hit attribute - please see the details there!
<meta name="kt:tileTitle" content="<clean, short - as much as possible title>">
The title of your content this Tile represents.
This is the equivalent to tileTitle hit attribute - please see the details there!
<meta name="kt:tileUrl" content="<the url of this tile>">
The URL of your content this Tile represents.
This is the equivalent to tileUrl hit attribute - please see the details there!
<meta name="kt:visitorType" content="free">
The type of the visitor who is interacting with the page at the moment.
This is the equivalent to visitorType hit attribute - please see the details there!
Well... To put it short: Keytiles will go with the "best effort" approach. Which means regarding the
use the OpenGraph og:title <meta> tag (in the page) if present, if not then <head>/<title> tag in the page
everything will be "article" - except the root url (so http://mywebsite.com/) which will be "frontpage"
will be the URL simply
This is simple so far, relatively straight forward. But here comes the tricky part, because from this point Keytiles will heavily assume your URL structure is good enough!
it will be calculated from the URI - if you have a page at http://mywebsite.com/a/b/mycontent then the URI (highlighted) will be hashed with an MD5 hash and this will become your tileId
staying with the above example, it will be "/a/b" at this point - so basically the last part ("mycontent") is cut out and what is left will become the tileGroupPath
The above simple "best effort" algorythm works pretty well actually in most cases - providing a 85-90% accurate view. But it will have several side effects too when things come to more interesting cases...
A very good example to that case is this: use case "Same content - but approached from different places" - you find this in the Example use-cases for attribute values section in our article explaining the hit attributes.