Traffic... period. It's different on every network despite the similarity of the apps etc. used in each company. The "perfect" signature is very difficult to write unless the traffic is so simple you could almost watch it go by on the wire yourself. The more complicated the target packet payload, (and the potential that it may be split across packets), the more difficult it is to maintain the accuracy of the signature. As the complexity of the target payload increases the amount of "normal" traffic that inadvertently "collides" with it increases too. While that traffic may not collide head on, (Alert), it is very close. Then it comes down to the myriad of settings etc. on the individual network that alter packet data slightly... Pretty soon, a sig that functions perfectly on 1000 other networks, is firing alerts in the hundreds or thousands on your network. For example... The eDonkey alerts over my SSL OWA connection. How could that happen? The traffic is encrypted - yet, when this _one_ user SSL OWA's from his home I get a stream of eDonkey Alerts for the entire period he is connected. The way I see it is that it must be the "keepalive" packets - I haven't bothered to sniff it yet because I pretty much understand the nature of this beast. The keepalive must contain some kind of session key or something that varies from user to user - it must, I don't get the alerts from anyone else. Unfortunately, this user's key triggers the eDonkey Alert. A perfect example of a rule becoming more complex that, under the correct circumstance, will collide with benign data for no good reason.
You say one mans false positive is another’s’ positive and but why is this