Well the idea of context based animations is a buzz word that has been kind of lost as to ways and means under Unreal 4.
This is the base theory used in a different engine.
The theory is the animation migration should be switched in the locomotion state is away that only the relevant animation states are used as to the needed state changes and eliminate states that are not needed with in the state machine that are switched to using an inline argument which may or may not be true at any given time as to state change rules.
This is where the idea of context based animations comes in, this case locomotion, as in any give state the animations can only be in a single relevant state at any given time.
Your player can not be in running state at the same time that it’s in a walking state so unifying the two under the same state machine will limit blending options between states as in most cases, using inplace, the state change has already changed and wait states are created to allow left and right foot placement to catch up.
How a tree works, instead of a state machine, is to break up the required relevant states into blocks based on the context of the required movement and use a nod like blend on int, or any other value based switch, so that the switch occurs based on the current state relevant to the desired animations. The benefit is the animation state switches the moment the event occurs with out exit arguments typical of a state machine migration path. The other benefit is you can also make use of the blending options of the weights into and out of the different blocks with out including them as part of the state machine.
I found this pathway to work well with sync markers and groups as it allows UE4 to do it’s thing with out the need for arguments to switch messing up the sync as the switch is an absolute with zero lantancy introduced by inline arguments.
Sync markers are easy to figure out as they only tag the position of the animation as to an absolute once again but the second part required to make it work as to letting UE4 perform the sync for you is to place the relevant animations into a group so the UE4 “knows” that the markers are related based on the context in which the animations is to be used. You could for example create a group called running and that group could be added to your tree.
How groups work.
OK so once in a group Unreal 4 will determine the the easy in and easy out points of the blend by default and as to the current rate so the trimming stays the same with out having to correct using inline hacks that once again adds lantancy. To be able to do this a leader is selected and all takes added to the group will have their frames adjusted to the same length as the leader. If the leader is 20 frames the all takes as part of the group will be length to 20. This makes it easier for UE4 to find the ease in point when say of the right foot and needs to blend to the left with out sliding or funky crossovers usually corrected by forcing the animation to wait until the animation is a position.
This is a free lunch on the part of UE4 as the requirements to make it work is provided by the engine so as long as the relevant animations are part of the group, be it in a blend space or not, then the engine will preform the proper foot blending for you.
Sorry for being a bit wordy but sync markers and groups is one of those things that hard to understand at first but becomes easy the more you use it and using context animations along with switching trees increases the number of blending options that is made difficult trying to shoe horn everything into a single state machine that may or may not work as to expectations.