DTM has a (number of) "page views" condition. It keeps track of this within its own library, and it is incremented each time the library is loaded. Adobe Analytics isn't part of the DTM library and is just a tool implemented through the library, same as any other tool or tag (albeit more integrated than say, Google Analytics tool, since it is an Adobe product, after all). But these are separate tools/libraries, so you will not find anything in AA's s object related to DTM's page view incrementor.
If you want to be able to reference the current value in your AA code (or custom javascript code in general), you can get it with the following:
// If you selected "Lifetime" radio button in your rule condition, use this
var lifetimePagesViewed = _satellite.visitorLifetimePagesViewed();
// If you selected "Current Session" radio button in your rule condition, use this
var sessionPageViews = _satellite.visitorSessionPagesViewed();
WARNING: DTM uses the methods above to evaluate rules with a "page views" condition. However, they are NOT methods listed as public facing functions that are "safe" for you to use. "Safe" - meaning, the functions work today, but they are internal functions and Adobe may change their namespace or behavior at any time without notice. So, if you use these functions, you do so at your own risk. (Having said that, I'm also going to throw it out there that Adobe has stated they do not plan on doing any major changes to DTM except fixing major issues if found, in favor of pushing development of Launch. So if I were a gambling man, I would say it is probably safe to use them. But that's on you to decide).
Meanwhile, Adobe Analytics considers a page view to be when an s.t() call is made, which may or may not line up with what DTM counts as a page view. This is mostly relevant if you have a Single Page App (SPA) where you trigger AA page view tracking on pushstate/hash changes (e.g. calling an Event Based Rule or Direct Call Rule after page load for (virtual) page view tracking), instead of a full page load (where DTM library does not keep reloading).
Adobe Analytics library itself does not have anything built in for tracking number of s.t() calls made (nothing public facing, anyways, and I've never really dug into the core library to see if there is anything internal). If you want to mimic DTM's method of counting, you can easily write your own cookie based code and put it into the AA lib custom code box in the tool config, to be executed during AA lib load. Note though that if your implementation includes suppressing the default AA page view tracking on DTM lib load, you will have to include that in your logic.
For SPAs where you make s.t() calls without full page loads, this becomes trickier. You basically have two options:
a) Add your cookie based logic everywhere you make an s.t() call. So basically in every Event Based Rule or Direct Call Rule you have that triggers an s.t() call, you will need to add your code to the custom code box to increment your cookie value. The benefit of this method is you can increment the cookie at a time where you can still include logic for popping AA vars or whatever off it in real time. For example you can have "page view == 3" logic and do say s.events ="event3" on the 3rd page view. The biggest drawback is you have to replicate / maintain the logic everywhere you have something that makes an s.t() call, which can conceivably become very unwieldy depending on your implementation.
b) There is a callback function baked into Adobe Analytics library called registerPreTrackCallback (and there is also a registerPostTrackCallback; you can use either one for this purpose, it doesn't matter). Basically, you can register a callback function to be called whenever any s.t() or s.tl() call is made. And within that function you can parse the AA request URL to determine if it is an s.t() or s.tl() call and then increment your cookie if it is the former.
Here is an example of a session scoped page view counter incremented on every s.t() call:
s.registerPreTrackCallback(function(requestURL) {
if (!s.Util.getQueryParam('pe', requestURL) &&
!s.Util.getQueryParam('pev2', requestURL)
) {
var sessionPageViews = +s.Util.cookieRead('s_sessionPageViews') || 0;
sessionPageViews = '' + ++sessionPageViews;
s.Util.cookieWrite('s_sessionPageViews', sessionPageViews);
}
});
This code should be placed in the AA's tool config custom code to be executed during library load. Whenever an s.t() call is made, the callback function will look for two URL params in the AA request URL "pe" and "pev2". Their presence indicate that it is an s.tl() call so the condition is to trigger the cookie incrementor code if they are NOT present. If they are not found, then we have some code that retrieves the current value of the cookie, increments it by 1, and then sets the cookie again.
Then, in whatever code or condition you want to reference it, you can read the "s_sessionPageViews" cookie to get the current value. The benefit to this method is it is a "global" implementation, so you don't need to worry about including the cookie incrementor code in every Rule that makes an s.t() call. The biggest drawback to this method is it increments the cookie after the s.t() call has been made, and after a point where you can set AA vars before the actual request. So the net effect here is you are lagging one page view behind. For example, if you want to include "page view == 3" logic and do say s.events ="event3" on the 3rd page view - this is not possible with this method, because the the cookie will not increment to 3 until after you pull the s.t() trigger, and after a point where you can populate any more AA vars. So, keep that in mind for whatever you are doing.
Preemptive strike: I am sure someone out there might comment about throwing logic in s_doPlugins callback, since it happens after the s.t() call is made, but before the request URL is actually sent out. The problem is s_doPlugins triggers many times on a page, even without an s.t() or s.tl() call is made, even if an actual AA request is never made. For example, throw a console.log into it and click on some random non-link element on your page and you will see it trigger. Meanwhile, there are ways to determine if an s.tl() destined to make an actual request is happening within s_doPlugins by looking at a combination of s.linkType, s.linkObject, and s.linkName. But there is no equivalent for s.t() calls!.
