Data Server: Why does my trigger fire unexpectedly more often than desired?

1. Triggering logic runs every time data within a Triggerable ERTD stream changes and if a condition continues to evaluate to true, it will fire the action. So if you have a trigger that is supposed to fire when the All Sport's Penalty_Flag = "FLAG", the logic will trigger the action once every second when the clock time changes because a new packet is received, which updates the table containing all of the All Sport Data.
 
Wrap your trigger in a 'Changes' condition for the particular data field so that if the field you care about didn't change since the last time data was received, then the trigger is skipped.

Also consider in some cases using a `Trigger Once` behavior if you truly want the trigger to only occur one time during an event. Trigger Once behavior must be reset manually by stopping the triggers package and restarting it, so this behavior is not typically recommended unless you are sure. Examples might be to trigger a special message when your Quarterback passes over 300 yards. A '>' check would continue to evaluate to true even if the data changes. However if a stat correction is made or the quarterback passes for negative yards to go back to 299 then later surpasses 300 again a 'Trigger Once' behavior prevents the celebration message from displaying twice in the game.

 
Note: Care and testing should be taken when combining or nesting multiple 'Changes' conditions. Sometimes the two data fields update in different ERTD packets resulting in neither run of the trigger logic where both fields changed.

2. Subtle bugs can occur when using multiple 'Change' conditions. This can occur if a 'Change' condition is OR/ANDed with another 'Change' condition or if a 'Change' condition is nested somewhere within the chain of another 'Change' condition.
This is because 'Change' conditions store the value from the last time the condition was evaluated to see if it changed (values are null if they haven't been evaluated yet). So if a 'Change' condition isn't evaluated for any reason, then the next time it is evaluated it may not be comparing its data against the previous packet, but instead against the value of the data the last time the 'Change' condition was evaluated.

For example, if you have two conditions based on a countdown clock: Minutes_Changed and Seconds_TensDigit_Changed and you OR them together in another condition… then every time the minutes value decrements (for example from 20:00 to 19:59) this condition will evaluate to true for two consecutive data packets.
First - it will detect that the minutes value changed (from 20 to 19) is true and due to it being an OR condition it doesn't need to check the second condition and continues to trigger its actions and nested triggers.
Then when the next packet is received (containing 19:58) it detects that the minutes value has not changed so then checks the 2nd condition of the OR and thinks that the Seconds_TensDigit value changed (from 0 to 5) is true because the last time it evaluated this condition the stored value was 0 from 20:00 (as it never evaluated this condition at 19:59 to update its locally stored 'previous value' to 5).
 
Similar bugs can happen with nested and AND conditions because if the first 'Change' check returns false then the nested or ANDed condition is never evaluated resulting in future evaluation comparing against older data.
 
Avoid ORing, ANDing, and nesting 'Change' conditions. Generally it's best to keep Change conditions as close to the root level as possible and never nested within eachother (they can be siblings though at the root level and when grouped by a SubTriggers = All).
For the specific example of Minutes_Changed and Seconds_TensDigit_Changed. You can also simply add another custom field to the custom DID for the combined minutes and seconds tens digit together: '19:5' (mm:s) and then you don't need to OR the minutes and seconds tens digit checks as when the clock changes from 20:00 to 19:59 the value of '20:0' will change to '19:5' with a single 'Change' condition trigger.

3.'>', '<', 'StartsWith', 'EndsWith' and 'Contains' checks can continue to resolve to true even when the data changes.
 Score > 60 is true for 61, 62, 63...     Data contains "1:3" is true for "1:39" through "1:30" and even includes the "11:30"s
 
Multiple things can be considered to help here.

1. Consider if '=' conditions would work in place of '>' or '<'
2. Consider if 'StartsWith' or 'EndsWith' would be better than 'Contains'
3. Consider if a modified DID that targets a smaller portion of an ERTD field allows for better 'Changes' detection (requires custom did work)  i.e. 'Main Clock Seconds Tens Digit' Changes && 'Main Clock Seconds Tens Digit' == "10:3"
4. Consider using the 'Trigger Once' behavior if applicable to your situation