There are typically two important metrics:
Order to Accept. This measures the round-trip time it takes your application to send an order to the exchange and get an accept, cancel, or execute back. Think of it as the minimum amount of time required for you to ask the market to do something and know whether it's been done. This plays an important role when building execution logic in models.
Order to Feed. This measures the amount of time it takes for an order or action to be represented in the venue's multicast depth of book feed. Depending on venue and other factors this can be faster than Order to Accept.
Other measures of latency can always be conjured. Some folks consider Model Latency, or the amount of time it takes a model to receive a piece of data, perform some calculation, and act upon it. Most numbers you see people discussing and passing around are worthless because you have no frame of reference as to what exactly they mean.
Remember, latencies are almost always relative. For example, the above metrics will of course be impacted by your specific co-location situation relative to the venue. That means your Order to Accept measure will be different from someone else's unless they are co-located in the same place as you (which is not uncommon, of course).
Underlying all of this is transit latency that the network imposes. As you can imagine the move towards co-location was driven by the fact that eliminating transit latency was quite easy by increasing proximity to the matching engine. I don't consider transit latency to really be a first-order metric for a trading system since it is built into the important domain specific metrics like I described above. However, it's always measured to ensure the critical network paths are behaving properly.