Multi-channel funnels is a new feature in Google Analytics, allowing to see how different marketing channels interact to create sales and conversions.
For example, many people may purchase on your site after searching for your brand on Google. However, they may have been introduced to your brand via a blog or while searching for specific products and services. The Multi-Channel Funnels reports show how previous referrals, searches, and exposure to other channels contributed to your sales.
Multi-Channel Funnels reports are generated from conversion paths, the sequences of interactions (i.e. clicks/referrals from channels) during the 30 days that led up to each conversion and transaction. Conversion path data include interactions with virtually all digital channels.
Channels
These channels include, but are not limited to:
paid and organic search (on all search engines along with the specific keywords searched)
referral sites
affiliates
social networks
email newsletters
display ads
custom campaigns that you’ve created, including offline campaigns that send traffic to vanity URLs
Reports
The multi-channels funnels reports include the following information:
Summary: Number of conversions and channels that have been involved
Main routes: Sequence of interactions that carried out a conversion. The data can be organized according to "source" (myweb.com, google, bind,...), "medium" (organic, referral, cpc, none,...), "keyword" (visitor search phrase) or "campaign".
Assisted conversions: Performance of traffic sources based on the number of times they have intervened in a conversion
Time Lapse: How slow have been your users to convert
Path Length: How many sources have interacted with users before making a conversion
The following video by Google provides an introduction to Multi-channel funnels:
I would like to give some short overview on the architecture of web browsers in general.
Browser functionality
The browser main functionality is to present the web resource you choose, by requesting it from the server and displaying it on the browser window. The resource is usually an HTML document, but may also be a PDF, image, or other type. The location of the resource is specified by the user using a URI (Uniform resource Identifier).
The way the browser interprets and displays HTML files is specified in the HTML and CSS specifications. These specifications are maintained by the W3C (World Wide Web Consortium) organization, which is the standards organization for the web.
For years browsers conformed to only a part of the specifications and developed their own extensions. That caused serious compatibility issues for web authors. Today most of the browsers more or less conform to the specifications.
Browsers' user interface have a lot in common with each other. Among the common user interface elements are:
Address bar for inserting the URI
Back and forward buttons
Bookmarking options
A refresh and stop buttons for refreshing and stopping the loading of current documents
Home button that gets you to your home page
Strangely enough, the browser's user interface is not specified in any formal specification, it just comes from good practices shaped over years of experience and by browsers imitating each other. The HTML5 specification doesn't define UI elements a browser must have, but lists some common elements. Among those are the address bar, status bar and tool bar. There are, of course, features unique to a specific browser like Firefox's downloads manager.
The browser's high level structure
The browser's main components are:
The user interface - this includes the address bar, back/forward button, bookmarking menu etc. Every part of the browser display except the main window where you see the requested page.
The browser engine - marshalls the actions between the UI and the rendering engine.
The rendering engine - responsible for displaying the requested content. For example if the requested content is HTML, it is responsible for parsing the HTML and CSS and displaying the parsed content on the screen.
Networking - used for network calls, like HTTP requests. It has platform independent interface and underneath implementations for each platform.
UI backend - used for drawing basic widgets like combo boxes and windows. It exposes a generic interface that is not platform specific. Underneath it uses the operating system user interface methods.
JavaScript interpreter. Used to parse and execute the JavaScript code.
Data storage. This is a persistence layer. The browser needs to save all sorts of data on the hard disk, for examples, cookies. The new HTML specification (HTML5) defines 'web database' which is a complete (although light) database in the browser.
It is important to note that Chrome, unlike most browsers, holds multiple instances of the rendering engine - one for each tab. Each tab is a separate process.
The responsibility of the rendering engine is well... Rendering, that is display of the requested contents on the browser screen.
By default the rendering engine can display HTML and XML documents and images. It can display other types through a plug-in (or browser extension); for example, displaying PDF using a PDF viewer plug-in. However, in this chapter we will focus on the main use case: displaying HTML and images that are formatted using CSS.
The rendering engine will start getting the contents of the requested document from the networking layer. This will usually be done in 8K chunks.
After that this is the basic flow of the rendering engine:
The rendering engine will start parsing the HTML document and turn the tags to DOM nodes in a tree called the "content tree". It will parse the style data, both in external CSS files and in style elements. The styling information together with visual instructions in the HTML will be used to create another tree - the render tree.
The render tree contains rectangles with visual attributes like color and dimensions. The rectangles are in the right order to be displayed on the screen.
After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen. The next stage is painting - the render tree will be traversed and each node will be painted using the UI backend layer.
It's important to understand that this is a gradual process. For better user experience, the rendering engine will try to display contents on the screen as soon as possible. It will not wait until all HTML is parsed before starting to build and layout the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the contents that keeps coming from the network.
Main flow examples
From figures 3 and 4 you can see that although Webkit and Gecko use slightly different terminology, the flow is basically the same.
Gecko calls the tree of visually formatted elements a "Frame tree". Each element is a frame. Webkit uses the term "Render Tree" and it consists of "Render Objects". Webkit uses the term "layout" for the placing of elements, while Gecko calls it "Reflow". "Attachment" is Webkit's term for connecting DOM nodes and visual information to create the render tree. A minor non-semantic difference is that Gecko has an extra layer between the HTML and the DOM tree. It is called the "content sink" and is a factory for making DOM elements.
You can find more information in the following tutorial.