"Additional authenticated data" is whatever you wish it to be. GCM is an authenticated encryption mode in which the inputs are:
- a key K suitable for AES (128, 192 or 256 bits);
- a 96-bit IV;
- some plaintext data P whose length is at most 239-256 bits (i.e. about 68.7 gigabytes);
- some additional data A whose length is at most 264 bits (i.e. about 2.3 millions of terabytes).
From these inputs, AES/GCM produces:
- a ciphertext C;
- an authentication tag T.
For decryption, you need these as inputs:
- the key K;
- the IV;
- the ciphertext C;
- the authentication tag T;
- and the additional authenticated data A (pay attention ! That's the tricky point).
Then AES/GCM decryption will produce either P (the plaintext), or complain loudly in case one of the parameters has been altered (i.e. the provided K, IV, C, T or A does not match that which was used or obtained during the encryption).
So what does that mean ? That means that an AE system, like AES/GCM, offers the following services:
It ensures confidentiality of P: adversaries who do not know K cannot guess anything about the contents of P, when they see only the other values (IV, A, C and T).
It ensures integrity of P and A: adversaries who do not know K cannot alter the IV, A, C and T values such that the decryption algorithm does not complain. So if the decryption works, then there is a good guarantee that the A and resultant P are identical to what they were when encrypting.
Nowhere in the standard is it specified how the various values should be concatenated, wrapped, or otherwise serialized for transmission. How C, IV, T and A are known to the receiver is completely out of scope, and is up to whatever protocol is using AES/GCM. The values needs not necessarily be transmitted. For instance, if you consider TLS 1.2 (and GCM-specific details): the IV is partially transmitted, and partially inferred (4 bytes from the handshake, 8 bytes with each record); the additional authentication data A is partially transmitted and partially inferred (concatenation of the record sequence number, protocol version and plaintext length); C and T are transmistted in the record body.
Any given protocol which uses GCM may or may not have need for the "additional authenticated data"; this is a feature of GCM: it can ensure integrity over more than the data which was also encrypted. Since both sender and receiver must know the same "additional authenticated data" for the decryption algorithm to succeed, that additional data may have to be transmitted, although it could also, in any protocol (as in the case of TLS), be inferred from context. In any case, that data cannot be recovered from the ciphertext C even with knowledge of the key, which is why it is called "additional".
Therefore, your first question makes no sense. AES/GCM output is not a sequence of bytes accumulating A, IV, C and T. AES/GCM produces two sequences of bits, C and T. Your question should be: is there a widely used protocol which builds on AES/GCM, and defines serialization formats for transmission of A, IV, C and T together ? And the answer to that question is: to my knowledge, no. There are some protocols, but nothing which qualifies as "widely used". In particular, in most cases, at least parts of A will be inferred from context, not transmitted, and the same could apply to parts or all of the IV. This makes it unlikely that a general purpose format emerges and is actually used everywhere.
The answer to your second question (length and contents of A) is: "whatever floats your boat". You don't encrypt and/or authenticate in abstracto, just for the sake of it. You encrypt and authenticate as part of an overall protocol used in a given context which dictates what should be encrypted and what should be authenticated (as is done in TLS).
As for your question about "whether random is sufficient" for the key, then the only possible comment is: I must respectfully ask, Sir, that you drop this keyboard and stop trying to do cryptography. Lest I should use violence.