When making use of the Adobe Client DataLayer extension and aiming to avoid direct integration of the data layer into the website's code, the question arises: Where should the data layer be included? Additionally, could you provide guidance on retrieving conversion variables within Omnibug?
I'm not really sure what you mean by "avoid direct integration of the data layer into the website's code"..
The purpose of a data layer is to surface information / data into an object that your tracking can read, extract information from, and potentially trigger tracking events...
If you have variables on the page that contain the information you want to track, you don't need a data layer (you're just duplicating those values into another format but that data already exists....) And using Launch to build a data layer from information that you can already see is somewhat redundant.
On top of this, if you want to be able to track information that you can't see already; how are you planning on getting that information without having it come from your website/developers? (things such as backend ids, or keywords that are used to drive display element on the page, etc)
Short story is, if you can extract the data from the page when it loads, you can use that data directly without a data layer, and if you can't see that data then there is no way to get it.
Data Layers are handy to pull all the data (what you can see and what you can't) into one centralized easy to use location... but if you are trying to build your own data layer using Launch (so as to not have this code integrated) you are doing a log of extra work, since you will have to do the initial extraction, then push it into the Data Layer, then extract from the Data Layer for your actual tracking.
Now, as for your Omnibug question... this completely depends on what your implementation is doing and what you are trying to track.
eVars or "Conversion Variables" are used in a variety of ways, and most current implementations use them for more than just "conversions"... Adobe themselves have been trying to encourage people to consolidate to using eVars in an effort to try and simplify the tagging system.
Now, that said, eVars have the complication of having a default expiry of "Visit", meaning that the value, once set, will continue to be set in the eVar until the end of the Visit (or the custom expiry that it's configured to) or a new value is set on it (again remaining until expiry)... but you won't see the "carry forward" value in Omnibug; you will only see the call where the value is set.
To quote a friend:
eVars can be set up to act like Props (Hit Expiry), and for a lot of uses now, when they are not being used as conversions, Hit is the proper expiry (Page level dimensional data like Page Title, URL, etc)
Now, there are also metrics that you might fire on a conversion... some of these are standard (purchase, scAdd, etc) but there are also custom events (event1, event27, etc)
Events are passed as a comma separate list in the events item on the action that you can see in Omnibug:
events = "event1,event27,purchase"
Other standard events like Page Views and Occurrences aren't passed specifically in the tracking, they are calculated during the process of the data.
Your web page's HTML can be like this:
<html> <body> <script> var adobeDataLayer = adobeDataLayer || ; adobeDataLayer.push(...); </script> <script src="URL-of-your-Launch-snippet" /> ... </body> </html>
i.e. define your "adobeDataLayer" before the Launch snippet script. When your Launch script runs, it loads the ACDL extension, and the extension will use the "adobeDataLayer" from your web page's HTML code.