Using calculated metric with custom attribution window in segment builder

[mitchhowell]

I'm trying to use a calculated metric within the segment builder, and it's not showing up. I can see the metric in the calculated metrics section, and in workspace, but it does not show up in segment builder. I suspect it might have something to do with the fact that it uses a custom lookback window.

The reason I'm trying to use this metric in a segment is because of an issue with lookback windows. We were using a visitor container in a segment and it was causing lots of inconsistency in our reporting when we pull different date ranges. So we changed it to visit window and it was too narrow. So we were trying to split the difference with a custom 90-day lookback window on this metric.

[Jennifer_Dungan · Accepted solution]

Unfortunately, calculated metrics cannot be used in Segments...

Maybe if you explain what you are trying to achieve, we might be able to help find a solution to create the segment you need.

[Harveer_SinghGi1]

Hi @mitchhowell ,

As @Jennifer_Dungan mentioned calculated metrics cannot be used in segments but based upon the definition you have for your calculated metric you might be able to recreate the logic in segment manually. So if you can share more details it will be helpful in figuring out what can be done.

Cheers!

[mitchhowell]

Thank you both for the responses. I'm trying to exclude customers from this segment. In this case, we have an event created for logins to our app. In the past, a visitor container was being used to exclude the most people possible, so that they'd be excluded from subsequent visits after having logged in recently. However, this was wreaking havoc on the data consistency since visitor containers adjust the lookback window depending on the date range. 

For example, for the month of January 2025, the number of visits was significantly different for the date range Dec - Jan than it was for Sep - Jan. My understanding is that this was because of the visitor container within that segment. We cannot have that much inconsistency when pulling the data with this segment.

So I tried a visit container instead, and it was too narrow. There were far more visits that came through than with the visitor container. So I tried to find a middle ground by creating a calculated metric that used a custom attribution model (last touch, 90 day window) whose lookback window was a consistent length.

I'm now understanding that my custom metric cannot be used in a segment. Any other ideas for using custom attribution models in a segment? Or for how to address this broader problem I'm dealing with?

[Jennifer_Dungan]

That does sound like an issue... One of the main problems I have with the Adobe segments is exactly the issue you touched on... the scope doesn't always work effectively....

So if I am understanding correctly, you are trying to exclude "logged in users" right? Based upon the current time frame?

One of the things I do in my sites, is I track both the "login action" (i.e. the actual event where a user logs into the site... but since we have a rolling authentication cookie, users may have logged in 3 years ago and still be logged in today).. but I also have tracking on each page view and action (every tracking event on the site) that tells me if a user is logged in or not on that hit. I also track user UUID and other information, like if the user is a subscriber, etc on every hit.

When I am trying to understand information about the action of login, and if there are potential pain points / failures / etc with the login flow, I use the login event... 

But for trying identifying my users by logged in or logged out, or subscriber or non-subscriber, I use the hit based dimension in my segment logic.

Unfortunately, this doesn't help you with historical data... and I am not sure how your login system works, if it too is a rolling session... this makes identifying the status more difficult...

Let me think about more potential ideas, but any more information you can provide about what data you have to work with and how your site works (and how you are identifying your customers) would be helpful.

[mitchhowell]

Oh that's helpful info! I am not familiar with that method of associating previous behavior with current data. I'm checking to see if we have a cookie like that where we store any similar data. 

I believe that most of the data we have available comes from events tracked within Adobe. We are storing data for clicking the login button, but I don't think we have adobe implemented all the way across our customer app. We did just set up a few specific API calls sending data from the customer app into our analytics instance.

[Jennifer_Dungan]

Even cookies aren't always reliable... particularly now with things like ITP deleting cookies after 7 days... 

Now, if you have a login/authentication cookie, you might be able to read from that.. if the user has the cookie, they are logged in... I send that data on every tracking event because it's an affirmative "yes" or "no" status.. if the cookies were deleted (either by the user or the browser), or if the cookies somehow got corrupted, or if something failed to track on the logout action...  There are too many "what ifs" to rely on looking at a login action with no logout following it to assume that the person is logged in... 

But, this doesn't necessarily help you now, because it requires new tracking, and the data can only be pulled going forward....

[Harveer_SinghGi1]

Hi @mitchhowell ,

If my understanding is correct, what you are trying to create is a logic to exclude the post-login hits from the visitors while keeping the hits pre-login for same visitors. So, something like below,

If that is the case then I think this can be achieved through include configuration in a sequential segment.

So here's the segment that you'll create,

This is how this segment works, the sequential logic with include after configuration returns only the hits after the user's first sign hit, then using exclude option we exclude all these hits and thus we are left with visitors entire history upto first sign in hit. You can compare the include options as below,

Now when you use this segment in reporting, as we are excluding hits after the first sign in of the users you can expect two types of results,

• Different reporting period keeping start day will return same visitor count - This happens because the report start day stays same so their first sign in during any period starting with a particular start day will not change
• Different reporting period with changing start day may return different visitor count - This happens because as the report start date changes, based on that their first sign in during the report period may have happened on a different hit change and it is expected

This can be validated in below reports if you look at Oct-24 data,

Hope this is helpful.

Cheers!

[Jennifer_Dungan]

Yes, unfortunately, this segment only looks at "Login Actions" within the panel date range... 

Running this on "Jan 2025" for instance, wouldn't take any of the logins from Dec, or Nov, or... but those users might still be logged in... unless the login expires with the session... 

But, if the login expires with the session, the segment can be simplified to just:

Visitor [

    Sign-Ins exists

]

This will get all visitors that logged in at least once during the date range...  you really don't need the extra logic... 

Update: 

The extra logic is good for only excluding visitors after they have logged in... but it doesn't take into account logouts either... if you really want to exclude users while for the duration of their logins, tracking the login status, and looking at:

Hit [

   logged in equals true  (or false)

]

is still much more reliable... 

[mitchhowell]

I hadn't thought about using a sequential segment! This one could be useful, but the problem of date range affecting the data inconsistently is still too problematic for us. This is for a segment that will be used by a large team of people, so we need it to be consistent, regardless of the reporting range. 

The idea is to exclude any user who has logged in, ever. That would be ideal. And that's probably exactly the use-case for a visitor container, it's just that I can't accept the tradeoffs in this case. 

[Jennifer_Dungan]

That used to be possible... before they changed the segment logic... Segments used to look at the entire history of the user (outside the date range) - or at least as far back as you have data retention....

Then the report would show the users that were active during the range.

However, since they added relative date range logic, the date is calculated at a different point in the logic, and now restricts the segment to the panel range... no more "ever in the history of the user" 

[Harveer_SinghGi1]

Hi @mitchhowell ,

Shouldn't this be achievable by creating a simple segment with date range in it which is equal to the data retention period for you? So if you have retention period of 36 months then create a date range as below,

Then simply join it with you logins exist clause in the segment like below,

This will not be impacted by panel date range unless you enabled the relative date components option which by default is disabled.

Cheers!

[Jennifer_Dungan]

Unfortunately, adding a date range inside a segment like that will overwrite the panel date range... the table will return 3 years worth of data all the time.

[Harveer_SinghGi1]

Ohh right.. this is interesting use case, would love to see if any of other experts have any thoughts on this.

[Jennifer_Dungan]

Yeah, this is something I used to be able to do (i.e. Identify Visitors that had ever been a subscriber, and see who was still active)... but since the segment logic redesign, I haven't found a solution... 

[Sukrity_Wadhwa]

Hi @mitchhowell,

Were you able to resolve this query with the help of the provided solutions, or do you still need further assistance? Please let us know. If any of the answers were helpful in moving you closer to a resolution, even partially, we encourage you to mark the one that helped the most as the 'Correct Reply.'
Thank you!