Storing a natural number as a set of its Nth prime factors, how much data is used? Spoiler, tap to reveal.

 In the answers, DanaJ demonstrates encoding natural numbers, as a set of Nth prime factors, as described in the question below, taking about $1.2$ to $1.5$ times the bits as using a more straightforward single binary number encoding.


A natural number can be stored as its prime factors, for example:
$10 = 2*5 = product(2, 5)\\12 = 2*2*3 = product(2, 2, 3)\\13 = 13 = product(13)$
And it's prime factors, being prime numbers, can be stored as the "position" of the prime that they are.
$p(1) = 2\\p(2) = 3\\p(3) = 5\\p(4) = 7\\p(5) = 11\\p(6) = 13$
Therefore: (Let $C$ be the name of a new function)
$10 = 2*5 = p(1) * p(3) = product(p(1), p(3)) = C(1, 3)\\12 = 2*2*3 = p(1) * p(1) * p(2) = product(p(1), p(1), p(2)) = C(1, 1, 2)\\etc\ldots$

The density of primes decreases with magnitude, larger adjacent primes being spaced further apart.
For example, the primes between $10$ and $20$ are $11, 13, 17$, and $19$, but $1000$ to $1010$ contains just one prime, $1009$.
However larger numbers tend to have more factors.

Question:
Typically, roughly how many times more data should it take to store numbers as described, than in the usual single binary number way?
Is this approach more efficient for larger numbers?

Following is an example with a 2 digit, and a 4 digit number.
I've included roughly how many binary bits could be required for this in square brackets. This is probably an underestimate as it doesn't count everything such as storage for the lengths of the numbers, or the storage for the length of the list of numbers. I'll use $n$ to represent this additional cost.
I'll represent for example $C(2, 3, 3, 6)$ as $C(+1, +1, +0, +3)$, this works because consecutive values never decrease.
.
$35\ [5\text{ bits}] = C(+2, +1)\ [2+1+n\text{ bits}]\\1822\ [11\text{ bits}] = C(+0, +155)\ [0+8+n\text{ bits}]$
 A: TonyK has shown that in general no encoding scheme can compress some strings while not expanding any string. But there is another problem with your idea that he didn't mention. You did not count the bits necessary to separate between the indices in your representation. They must be counted, otherwise you are hiding information in the position of the separators (you used commas in your question). Also, if you want to encode arbitrary natural numbers with asymptotically optimal bit length, you need some kind of recursive encoding such as Elias delta coding. This coding is prefix-free and hence does not need separators.
A: You can't get something for nothing. There are $2^n$ binary strings of length $n$, so you can't use them to represent more than $2^n$ different integers. Therefore $-$ necessarily $-$ if your encoding is more efficient for some integers, it must be correspondingly less efficient for other integers.
A: I have interest in this theory for a while
What I'm thinking about now is, it could be possible to have many level of product store as number
I mean, for example we could represent 1787 as prime(277)
And 277 is also prime at index 59 so we could said 1741 is prime(prime(59))
or 2411 is prime at index 358 and 358 is 2 * 179 so we could write prime(2 * 179)
And 179 is prime so maybe we could write it as prime(2 * prime(41))
What we could store is 2:[52] for 1787 and 1:[2,1:[41]] for 2411
If we find some cap number that, if the number is more than cap number it will recursively reduce in this manner until it small enough
It could be able to encode megabyte of data serialize into this manner smaller than the data?
