<p>you subscribe to the wss feed you can see most the subsecond stuff is opening and canceling limit orders which doesn't effect the ticket price. Only market orders represent the exchange of bitcoin. Market orders are liquidity takers so get a fee. They represent actual market movement. The limit orders often will never get matched. I often market orders may only come in every minute to five minutes under normal trading atmosphere. So ticker price more constant. Hope this help.</p>

CC BY-SA 4.0
2018-05-13T20:26:21.377Z
thanks for the reply. So am I correct in understanding that the data that I posted is just orders on the book, not necessarily *matched* orders that moved the ticker price? If so, it sounds like it's not possible to tell what the actual ticker price is at a time from the data that I have? I would need to find another data set that shows the actual ticker price per second if I want to back-test a program that functions on the ticker price? I got my data from http://api.bitcoincharts.com/v1/csv/ if that helps.
NZHammer
CC BY-SA 4.0
2018-05-14T06:48:49.053Z
Market orders never go on the book, it would be open limit orders leaving book, but how can you tell if it matched or was simply canceled. Most transactions are open/closing orders. Basically algorithms jockeying for positions etc. Much fewer are exchanges of bitcoin. So really it's not as active as it may appear. Sometimes though it can speed up like in sudden market rise or dip. Usually spurred by a large market order filling.
marshal craft
CC BY-SA 4.0
2018-05-14T06:53:08.963Z
You should use the gdax websocket feed. It relays the most granular information nearly as soon as it hits the market. Delay depends on your physical location and market conditions. Also for different order books from the rest API, especially lvl 3, your explicitly not supposed to periodically request. Instead start wss feed and then get book and proceed updating the book with the feed using the book and wss transaction sequence number, kind of like bleeding breaks for air tight book.
marshal craft
CC BY-SA 4.0
2018-05-16T00:58:03.310Z
Ok, I've been checking price by getting the ticker value every 30 seconds and checking my order statuses every few seconds to see if any of them have filled (Both REST API). I avoided web sockets because I figured that was more than I needed for my simple program, but I will look into them more. Thanks for shedding light on what I was actually looking at with the raw data I posted. It makes sense now. I'll up vote / accept when I have the points to do so.
NZHammer
CC BY-SA 4.0
2018-05-17T17:07:00.743Z
Yes the rest API is easy, but if you can handle authenticated rest API wss subscription should be easier.
marshal craft
CC BY-SA 4.0
2018-05-17T17:09:15.263Z
Also 30 second poling probably isn't a problem but if you want to know stuff as detailed as you ask you simply should use the wss feed.
marshal craft
CC BY-SA 4.0
2018-05-17T17:11:30.503Z
It all depends on the fidelity you need.
marshal craft
CC BY-SA 4.0
2018-05-11T12:09:31.353Z
2018-05-11T12:09:31.353Z
marshal craft
<p>I am trying to understand how a ticker price is determined for an asset, in this case I am specifically looking at BTC data from GDAX. The question stemmed when downloading historical BTC data from GDAX and seeing the following (truncated): </p>

<p>1516099829,11921.070000000000,0.008100000000
1516099829,11921.070000000000,0.037873260000
1516099829,11921.070000000000,0.031519050000
1516099829,11921.060000000000,0.037464080000
1516099829,11920.000000000000,0.001000000000
1516099829,11912.530000000000,0.001678900000
1516099829,11909.000000000000,0.000100990000
1516099829,11908.360000000000,0.001000000000
1516099829,11908.360000000000,0.001000000000
1516099829,11900.630000000000,0.001680580000
1516099829,11900.000000000000,1.293924550000
1516099829,11900.000000000000,0.132108480000
1516099829,11895.000000000000,0.000300000000
1516099829,11891.170000000000,0.000727720000
1516099829,11890.190000000000,1.400000000000
1516099829,11890.160000000000,0.000838510000
1516099829,11890.000000000000,0.058736000000
1516099829,11888.740000000000,0.001682260000
1516099829,11885.310000000000,0.252173310000
1516099829,11882.920000000000,0.841910000000
1516099829,11876.860000000000,0.001683950000
1516099829,11876.310000000000,0.000728620000
1516099829,11871.000000000000,0.000100990000
1516099829,11871.000000000000,0.000100990000
1516099829,11869.590000000000,0.010000000000
1516099829,11868.000000000000,0.000100990000
1516099829,11865.630000000000,0.010000000000
1516099829,11865.000000000000,0.001685630000
1516099829,11864.490000000000,0.900000000000
1516099829,11864.480000000000,1.113098000000</p>

<p>As you can see, the price fluctuates wildly in a single second. I understand that this data is accurate and shows all of the executed orders for the second, but I do not understand how the ticker value is determined for this second.</p>

<p>I am going off of the (possibly incorrect) assumptions that getting the ticker value from their REST API over and over would not show these wild fluctuations for a single second. I draw this conclusion because I have ran a loop that gets the ticker data over and over with just 300 ms delay and the price has never changed in the same second. As a matter of fact, it shows the same timestamp until the price changes, in which case it shows the new timestamp. This leads me to believe that there is something behind the scenes that is determining the ticker price per second based off all of the trades happening in that second.</p>

<p>If it helps, I am asking this because I want to back-test GDAX data for a program that I have written. In my program, I get the ticker data for the current point in time every two seconds, and receive one value back (the ticker price). Now, when back-testing and 1516099829 comes up, I do not know which price to use. My program will behave very differently depending on which data point I use because the prices vary so heavily.</p>

CC BY-SA 4.0
2018-05-10T20:51:21.593Z
Welcome to the volatility problem.
Hannah Vernon
CC BY-SA 4.0
2018-05-11T11:59:25.453Z
Very simply it's the last most recent market order which took the highest/lowest buy/sell order on book.
marshal craft
<transactions><exchanges><api><trading><gdax>
How is a ticker price determined?
NZHammer
# How is a ticker price determined?

(Asked by: username_0 on 2018-05-10)

I am trying to understand how a ticker price is determined for an asset, in this case I am specifically looking at BTC data from GDAX. The question stemmed when downloading historical BTC data from GDAX and seeing the following (truncated):

1516099829,11921.070000000000,0.008100000000
1516099829,11921.070000000000,0.037873260000
1516099829,11921.070000000000,0.031519050000
1516099829,11921.060000000000,0.037464080000
1516099829,11920.000000000000,0.001000000000
1516099829,11912.530000000000,0.001678900000
1516099829,11909.000000000000,0.000100990000
1516099829,11908.360000000000,0.001000000000
1516099829,11908.360000000000,0.001000000000
1516099829,11900.630000000000,0.001680580000
1516099829,11900.000000000000,1.293924550000
1516099829,11900.000000000000,0.132108480000
1516099829,11895.000000000000,0.000300000000
1516099829,11891.170000000000,0.000727720000
1516099829,11890.190000000000,1.400000000000
1516099829,11890.160000000000,0.000838510000
1516099829,11890.000000000000,0.058736000000
1516099829,11888.740000000000,0.001682260000
1516099829,11885.310000000000,0.252173310000
1516099829,11882.920000000000,0.841910000000
1516099829,11876.860000000000,0.001683950000
1516099829,11876.310000000000,0.000728620000
1516099829,11871.000000000000,0.000100990000
1516099829,11871.000000000000,0.000100990000
1516099829,11869.590000000000,0.010000000000
1516099829,11868.000000000000,0.000100990000
1516099829,11865.630000000000,0.010000000000
1516099829,11865.000000000000,0.001685630000
1516099829,11864.490000000000,0.900000000000
1516099829,11864.480000000000,1.113098000000

As you can see, the price fluctuates wildly in a single second. I understand that this data is accurate and shows all of the executed orders for the second, but I do not understand how the ticker value is determined for this second.

I am going off of the (possibly incorrect) assumptions that getting the ticker value from their REST API over and over would not show these wild fluctuations for a single second. I draw this conclusion because I have ran a loop that gets the ticker data over and over with just 300 ms delay and the price has never changed in the same second. As a matter of fact, it shows the same timestamp until the price changes, in which case it shows the new timestamp. This leads me to believe that there is something behind the scenes that is determining the ticker price per second based off all of the trades happening in that second.

If it helps, I am asking this because I want to back-test GDAX data for a program that I have written. In my program, I get the ticker data for the current point in time every two seconds, and receive one value back (the ticker price). Now, when back-testing and 1516099829 comes up, I do not know which price to use. My program will behave very differently depending on which data point I use because the prices vary so heavily.

**Tags:** transactions, exchanges, api, trading, gdax

> **Comments:**
> **username_1**: Welcome to the volatility problem.  
> **username_2**: Very simply it's the last most recent market order which took the highest/lowest buy/sell order on book.  

---

## 1 answers

### Answer by username_2 on 2018-05-11. Score: 0 | Accepted answer

you subscribe to the wss feed you can see most the subsecond stuff is opening and canceling limit orders which doesn't effect the ticket price. Only market orders represent the exchange of bitcoin. Market orders are liquidity takers so get a fee. They represent actual market movement. The limit orders often will never get matched. I often market orders may only come in every minute to five minutes under normal trading atmosphere. So ticker price more constant. Hope this help.

> **Comments:**
> **username_0**: thanks for the reply. So am I correct in understanding that the data that I posted is just orders on the book, not necessarily *matched* orders that moved the ticker price? If so, it sounds like it's not possible to tell what the actual ticker price is at a time from the data that I have? I would need to find another data set that shows the actual ticker price per second if I want to back-test a program that functions on the ticker price? I got my data from http://api.bitcoincharts.com/v1/csv/ if that helps.  
> **username_2**: Market orders never go on the book, it would be open limit orders leaving book, but how can you tell if it matched or was simply canceled. Most transactions are open/closing orders. Basically algorithms jockeying for positions etc. Much fewer are exchanges of bitcoin. So really it's not as active as it may appear. Sometimes though it can speed up like in sudden market rise or dip. Usually spurred by a large market order filling.  
> **username_2**: You should use the gdax websocket feed. It relays the most granular information nearly as soon as it hits the market. Delay depends on your physical location and market conditions. Also for different order books from the rest API, especially lvl 3, your explicitly not supposed to periodically request. Instead start wss feed and then get book and proceed updating the book with the feed using the book and wss transaction sequence number, kind of like bleeding breaks for air tight book.  
> **username_0**: Ok, I've been checking price by getting the ticker value every 30 seconds and checking my order statuses every few seconds to see if any of them have filled (Both REST API). I avoided web sockets because I figured that was more than I needed for my simple program, but I will look into them more. Thanks for shedding light on what I was actually looking at with the raw data I posted. It makes sense now. I'll up vote / accept when I have the points to do so.  
> **username_2**: Yes the rest API is easy, but if you can handle authenticated rest API wss subscription should be easier.  
> **username_2**: Also 30 second poling probably isn't a problem but if you want to know stuff as detailed as you ask you simply should use the wss feed.  
> **username_2**: It all depends on the fidelity you need.  

---

