Ok,
Just an FYI, the "Order" setting can be a little misleading... basically this is a stack rank of when to start the execution of a code block relative to other blocks in the same context... but they all technically run simultaneously.
So if you have 5 rules that are set to run at 10, 20, 30, 40, and 50, but let's assume that some scripts are slower than others. So, the rules in the same order by execution time (I am going to use unrealistically high values in seconds to make it easier): 5 seconds, 2 seconds, 3 seconds, 1 second, 1 second.
The first rule will fire, then a few milliseconds after that, the second rule will fire, etc...
The difference in time between the start of the rule is negligible, essentially, the rules will complete in the following order: Rule 4, Rule 5, Rule 2, Rule 3 then Rule 1. This is part of the asynchronous behaviour.
If there is only one rule being triggered, the "Order of 50" shouldn't make any difference at all, it just gives an easy way to start another script marginally faster if needed.
However, Click Tracking can be at risk of being lost because the page unloads as you said; and you might be right, I think the WebSDK might be able to defer some of that tracking til the next page (unlike AppMeasurement).
This piggyback onto the page view shouldn't cause any issues then...
In my implementation, I always try to collect Page View data along with Overlay, Promo Banner and Wall impressions (to reduce the number of server calls).... I don't want to send 5 server calls, when I can send one. This sounds like it's performing a similar cost savings, by deferring the click data to the next page... however, correlating that click tracking to the correct page might get tricky.
It you want to see what URL, or Page that click was made on, you might not be able to (since the tracking call has the current URL being passed)
Also, enabling Activity Map (in conjunction with your click tracking) shouldn't hurt anything either, in fact, it would probably help by providing additional context about what page, region and link that was clicked (all data from the previous page)...
I am not sure if automatic link tracking is related more to Activity Map, or actual additional server calls... It sort of looks like it might just be enabling "Activity Map" data.... but AA just isn't taking it into consideration....it sounds like you are collecting that data with WebSDK, but not sending it through to AA.
