Previous Tab Info on Mobile App

[jaishal]

I want to capture the previous tab info when the user lands on a specific page.

Example: 

If the customer is coming from page 1 and lands on page 2, on page tab, can we pass a variable which captures which page the customer is coming from ?

We pass this info on our website using v5 previous tab variable from the url itself. Which context data variable we have to pass for this info?

[Jennifer_Dungan]

We implemented something like this, to replicate Activity Map on our websites. So like Activity Map, we track the previous page, link text and link region. Passing the three values into 3 dimensions (the same dimensions we copy our Activity Map info into, so that we can create reports in Workspace that look at web and app together, or can be separated out.

I should note that our Web Implementation has done a lot of work to make the "regions" usable, by configuring our settings to use a custom data attribute for our region names (instead of just grabbing the nearest ID which is mostly unreadable).

Essentially, we broke our website it regions, things like "header", "footer", "main-menu", etc... including setting content block level regions to distinguish "news" or "sports" or "opinion" blocks (we are a news org, but blocks can be configured for any site to get the most out of your page layouts).

Now, on the app, all of this work had to be done by the developers... for every interaction, they needed to store the current page name, the link text (or for PII an alternate override text), and the designated region for the click... carry that forward to the next screen view, and add that as context variables on our trackState call.

I should note we are still using the ACP SDK, and not yet the AEP SDK... in theory, I believe that using AEP and XDM Schema, you might be able to pass the info directly into the Activity Map keys (if this is what you want to do, however, if you are using the Extension, this might cause some issues.... we don't use the extension, nor can I pass info directly to the Activity Map... hence my replication dimensions)

Since you are just passing data to eVar5 on your website (looks like previous URL), I would assume that each page / screen / tab in your app has a "logical" url that matches to its web counter-part... you should just instruct your developers to pass the previously set URL value as a context variable so that you can map it to eVar5 in processing rules... or if you are using the atags custom schema, in the XDM Stream, they can set the eVar5 value directly.

[Jagpreet_Singh_]

@jaishal  Did you find the suggestion helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

[jaishal]

Thanks Jennifer for the info. The issue highlighted by our devs is that for passing previous tab info, they need to keep track in the app which will increase memory and will get tough for them to maintain. I am just figuring out a way of how we can capture previous tab info in a different way. Any suggestions?

[Jennifer_Dungan]

I don't think you can? Mobile Apps aren't a website, you don't have access to scripting languages, or things like Session Storage to set a value on Page X and retrieve the value on Page Y.... as far as I am aware, you are at the mercy of tracking what your developers send you... 

It's not like the values stored have to be stored indefinitely... you will have a few items that will be used yes, but those will be refreshed with updated data on the next screen transition... I don't think that adding one or more fields for reuse is going to add significant overhead on the memory usage.... We didn't notice any issues on our implementation (3 reusable items to replicate Activity Map), and it's been running since 2020....

The only other option is to try and use things like the flow diagram, Previous Page panel, and complex segments to try and calculate this out after the fact...  but this is always a real pain...