When you use the part-synchronous embed code you do want that right before the </body>, because it starts with a blocking download of the bootstrapper. When you use the all-asynchronous embed code, the <head> would be better placement for the Munchkin bootstrapper, and in turn for the actual Munchkin library.
Either way, unless you have a very, very simple page, the actual analytics library is going to end up in the head.
I differ with the docs' recommendation that the all-asynchronous embed code be used by default (the Munchkin docs have factual errors, but this is more one of opinion). As I've written before, all web analytics libraries bear an inherent contradiction:
- On the one hand, we mandate that analytics must not impede webpage navigation, rendering, interaction, nor exit -- a low-priority, essentially disposable component.
- On the other hand, we require that analytics losslessly captures all interesting activities -- a high-priority, business-critical component of the marketer's toolkit.
These two missions cannot both be accomplished, even if you target only modern browsers. You might lean toward disposability... until you have to explain why your reports don't match with web server logs or other expectations. You might swing toward infallibility... until you see that geographically remote users are struggling with wait times.
Anyway, despite the contradiction, you can at least fit the best browser tech to the task. My Munchkin adapter (which Takehiro uses, or least used to) is one way to go about getting the best of both worlds. That doesn't always mean "async everywhere": it depends on site-specific (and sometimes page-specific) needs.
.png)