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

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!

What are <meta> tags?

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!

When to add <meta> tags?

It makes sense 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.

What do they do exactly?

If <meta> tags are present in your HTML source then they are recognized by our Tracking Script and they are influencing how KeytilesTrackingApi.buildHitOptions() method assembles the hit options.

<meta> tags reference

kt:tileId

<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!

kt:tileType

<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!

kt:tileGroupPath

<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!

kt:tileTitle

<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!

kt:tileUrl

<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!

kt:tileLabelsJSON

<meta name="kt:tileLabelsJSON" content="<valid JSON string encoding a JSON Object>">

You have the possibility to store a limited amount of labels - key-value pairs - with Tiles on Keytiles side. You get them back via the query result if you do so.

This is the equivalent to tileLabelsJSON hit attribute - please see the details there!

kt:visitorType

<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!

kt:primaryTags

<meta name="kt:primaryTags" content="<comma separated list of tags>">

You have the possibility to build custom segmentation of your traffic by tagging the Event sent to Keytiles.

This is the equivalent to primaryTags hit attribute - please see the details there!

kt:secondaryTags

<meta name="kt:secondaryTags" content="<comma separated list of tags>">

You have the possibility to build custom segmentation of your traffic by tagging the Event sent to Keytiles.

This is the equivalent to secondaryTags hit attribute - please see the details there!

OK but what does Keytiles do then without these <meta> tags?

Well... To put it short: Keytiles will go with the "best effort" approach. Which means regarding the

  • tileTitle
    use the OpenGraph og:title <meta> tag (in the page) if present, if not then <head>/<title> tag in the page
  • tileType
    everything will be "article" - except the root url (so http://mywebsite.com/) which will be "frontpage"
  • tileUrl
    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!

  • tileId
    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
  • tileGroupPath
    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.