Excel'de İki Analiz: PivotTable Panosu ve Çözücü ile Portföy OptimizasyonuTwo Analyses in Excel: A PivotTable Dashboard and Portfolio Optimization with Solver

81 ilin beş yıllık gayrimenkul satışları için PivotTable panosu ve dokuz BIST hissesi için Çözücü ile portföy modeli. İkisini de yeniden açtım ve ikisinde de bir hata buldum.A PivotTable dashboard for five years of property sales across 81 provinces, and a Solver portfolio model for nine BIST stocks. I reopened both and found an error in each.

  • Excel
  • PivotTable
  • Çözücü
  • Konno-Yamazaki
  • Veri kalitesi

Excel'i “tablo tutulan yer” sananlar için iki karşı örnek: 81 ilin beş yıllık gayrimenkul satışlarını PivotTable ve dilimleyicilerle inceleyen bir pano, ve dokuz BIST hissesinden Çözücü ile optimal portföyü bulan bir model. İkisini de yeniden açtım, sayıları doğruladım — ve ikisinde de düzeltilmesi gereken birer hata buldum.

Gayrimenkul verisi81 il2008–2012, üç satış türü
Toplam konut satışı3,0 milyon828.878'i ipotekli
Portföy modeli9 hisse21 işlem günü, Çözücü

1. Gayrimenkul satış panosu

İlk dosya, Türkiye'de 2008–2012 yılları arasında 81 ilde gerçekleşen gayrimenkul satışlarını içeriyor. Her il için yıl bazında üç kırılım var: toplam konut satışı, bunun ipotekli olan kısmı ve ipoteksiz (diğer) satışlar.

Pano tarafında iş PivotTable ile yapılmış: bölgelere göre satış dağılımı, bölgelerin satış türü kırılımı ve dilimleyicilerle seçilen il/yıl için satış grafiği. Dilimleyiciler, formül yazmadan etkileşim kurmanın en pratik yolu — kullanıcı il ve yılı seçiyor, bütün grafikler birlikte güncelleniyor.

YılKonut satışıİpotekliİpotekli payı
2008427.105—veri yok
2009555.18422.726%4,1
2010607.098246.741%40,6
2011708.275289.275%40,8
2012701.621270.136%38,5

Beş yılda toplam 2.999.283 konut satışı var; bunun 828.878'i ipotekli. Tablodaki en dikkat çekici sıçrama 2009'dan 2010'a: ipotekli satışların payı %4,1'den %40,6'ya çıkıyor ve sonraki iki yıl bu seviyede kalıyor.

Dikkat — bu bir “patlama” değil: 2008 sütununda ipotekli satış sıfır değil, boş. Kaynak veride 2008 için ipotekli kırılımı yok, hücrelerde tire işareti var. 2009'daki %4,1 de muhtemelen kısmi bir kayıt. Bu yüzden “2008'de ipotekli satış yoktu” demek yanlış olur; doğru ifade, ipotekli satışların ayrı raporlanmaya 2009–2010 döneminde başladığıdır.

İller arasındaki yoğunlaşma

İlToplam konutÜlke payıİpotekli payı
İstanbul734.098%24,5%34,1
Ankara521.305%17,4%26,5
İzmir192.462%6,4%33,1
Antalya156.848%5,2%23,7
Bursa93.905%3,1%31,5
Kayseri77.124%2,6%23,0

İstanbul ve Ankara tek başına ülke genelindeki konut satışlarının %41,9'unu oluşturuyor. İpotekli satış oranı da büyük şehirlerde yüksek: İstanbul %34,1 ve İzmir %33,1 ile ortalamanın (%27,6) üzerinde, Antalya ve Kayseri ise altında.

2. Panodaki hata: bölge atamaları kaymış

Panonun ana grafiği bölgelere göre satış dağılımını gösteriyor ve Akdeniz'i açık ara birinci sırada çıkarıyordu: 1.013.779 konut satışı. Bu sayı mantıklı görünmüyordu — Akdeniz bölgesinde İstanbul büyüklüğünde bir il yok.

Veri setindeki BÖLGE sütununu TÜİK'in İBBS Düzey-1 sınıflamasıyla karşılaştırdım. 81 ilin 18'inde bölge ataması yanlış.

İlDosyadaki bölgeDoğrusu
İstanbulAkdenizİstanbul
İzmirBatı MarmaraEge
KocaeliGüneydoğu AnadoluDoğu Marmara
KonyaDoğu MarmaraBatı Anadolu
MersinGüneydoğu AnadoluAkdeniz
KayseriBatı KaradenizOrta Anadolu
ManisaOrtadoğu AnadoluEge
MalatyaEgeOrtadoğu Anadolu

Tabloda yanlış atananların sekizi gösteriliyor; toplam 18 il etkileniyor. Hepsi alfabetik sırada İstanbul ile Mersin arasındaki aralıkta. Bu, hatanın tipik nedenini de söylüyor: bir sütun tek başına sıralanmış ya da bölge listesi il listesiyle hizasını kaybetmiş. Excel'in “yalnızca seçili sütunu sırala” uyarısının neden ciddiye alınması gerektiğinin ders kitabı örneği.

Hatanın etkisi küçük değil. İstanbul'un 734.098 satışı Akdeniz'e yazıldığı için bölge sıralaması tamamen değişiyor:

BölgeDosyadakiDüzeltilmişFark
İstanbul—734.098yeni bölge
Batı Anadolu538.846603.919+%12
Akdeniz1.013.779371.367−%63
Ege144.676318.315+%120
Doğu Marmara299.831259.708−%13
Güneydoğu Anadolu281.146179.155−%36
Orta Anadolu81.002160.947+%99
Batı Karadeniz203.816130.872−%36
Batı Marmara268.43168.773−%74

Düzeltmeden sonra liderlik Akdeniz'den İstanbul'a geçiyor, Ege'nin satışları iki katından fazla artıyor ve Batı Marmara dörtte birine iniyor. Toplam değişmiyor (2.999.283) — yalnızca doğru bölgelere dağılıyor.

İkinci bir ayrıntı: Veri setindeki TOPLAM sütunu, yıl bazındaki bütün kırılımları topladığı için her satışı dört kez sayıyor (örneğin Adana için 70.445 yerine 281.780 yazıyor). Bölge özetlerinden biri bu sütuna dayanıyor. Doğru özet, TOPLAM KONUT / TOPLAM İPOTEKLİ / TOPLAM DİĞER sütunlarından alınmalı.

3. Çözücü ile portföy optimizasyonu

İkinci dosya tamamen farklı bir iş: Konno-Yamazaki modeli ile optimal portföy seçimi. Klasik Markowitz yaklaşımı riski varyansla ölçer ve karesel bir problem üretir; Konno-Yamazaki ise riski ortalama mutlak sapma ile ölçer. Bunun pratik sonucu şu: problem doğrusal hale gelir ve Excel'in Çözücü eklentisiyle çözülebilir.

Veri

9 BIST hissesi

GARAN, HALKB, ARCLK, KCHOL, TUPRS, THYAO, TOASO, MGROS, TTKOM — 31.12.2020–29.01.2021 arası günlük getiriler.

Amaç

Mutlak sapmayı küçült

Portföyün günlük getirisinin ortalamadan sapmalarının toplamı en aza indiriliyor.

Kısıt

Ağırlıklar toplamı 100

Negatif ağırlık yok (açığa satış kapalı) ve hedef getiri alt sınırı var.

Araç

Excel Çözücü

Doğrusal problem olduğu için Simplex LP ile çözülebiliyor; ek yazılıma gerek yok.

Modelin sonucu:

HisseOrtalama günlük getiriPortföy ağırlığı
ARCLK0,532%99,49
GARAN−103,265%0,51
MGROS0,2930
TOASO0,2830
KCHOL−0,1240
THYAO−0,2640
TTKOM−0,3420
TUPRS−0,3450
HALKB−33,0240

Amaç fonksiyonu değeri Z = 509,52. Ama tablodaki iki satır hemen göze çarpıyor.

4. Portföy modelindeki iki sorun

GARAN ve HALKB serilerinde ondalık hatası

GARAN'ın ortalama günlük getirisi −103,27, HALKB'ninki −33,02 görünüyor. Diğer yedi hissenin ortalamaları −0,35 ile +0,53 arasında. Ham veriye bakınca neden belli oluyor: GARAN sütununda −85, −431, −225 gibi değerler var. Günlük %431 düşüş mümkün değil — bu değerler yüz kat büyük, yani ondalık ayracı kaybolmuş (−4,31 yerine −431).

Muhtemel sebep: veriler tr.investing.com'dan kopyalanırken virgüllü ondalıklar Excel'in bölgesel ayarıyla uyuşmamış ve iki hisse için ayraç yok sayılmış. Bu, dışarıdan veri alırken en sık karşılaşılan hatalardan biri ve sessizce gerçekleşiyor: hücreler sayı olarak görünüyor, formüller çalışıyor, hiçbir uyarı çıkmıyor.

Hedef getiri kısıtı tek bir çözüme zorluyor

Modeldeki hedef getiri kısıtı, ulaşılabilecek en yüksek tekil hisse getirisine eşitlenmiş (0,532 ≥ 0,532). Böyle bir kısıtta optimizasyonun yapabileceği tek şey var: parayı neredeyse tamamen o hisseye koymak. Nitekim sonuç ARCLK'de %99,49.

Bu, modelin değil kurgunun sonucu. Portföy optimizasyonunun amacı çeşitlendirme yoluyla riski azaltmaktır; hedef getiri maksimuma sabitlendiğinde çeşitlendirme imkânı ortadan kalkar. Anlamlı bir sonuç için hedef getirinin daha düşük bir seviyeye çekilmesi ve farklı hedefler için etkin sınırın (efficient frontier) çıkarılması gerekir: her hedef getiri için minimum riski hesaplayıp eğriyi çizmek.

Tekrarlasam ne yapardım: (1) getiri serilerini ham fiyattan yeniden hesaplar, ondalık ayracını kontrol ederim; (2) hedef getiriyi birkaç seviyede değiştirip etkin sınırı çıkarırım; (3) 21 işlem günü çok kısa olduğu için pencereyi en az bir yıla genişletirim. Üçü de modeli değiştirmeden, yalnızca kurguyu düzelterek yapılabilir.

5. Bu iki çalışma Excel hakkında ne söylüyor?

Güçlü yan

PivotTable

81 il × 5 yıl × 3 kırılımlık bir veriyi tek formül yazmadan özetlemek ve dilimleyicilerle etkileşimli hale getirmek dakikalar sürüyor.

Güçlü yan

Çözücü

Doğrusal bir optimizasyon problemi, ek yazılım gerektirmeden kurulabiliyor ve sonuç aynı dosyada duruyor.

Zayıf yan

Sessiz hatalar

Yanlış bölge ataması da, kaybolan ondalık ayracı da hiçbir uyarı üretmiyor. Dosya açılıyor, grafikler çiziliyor, sayılar yanlış.

Zayıf yan

İzlenebilirlik

Veri hazırlığı adımları dosyanın içinde kayıtlı değil; hangi sütunun nereden geldiği sonradan anlaşılmıyor.

Bu iki zayıf yan, aynı analizi R veya Python'da yapmanın asıl gerekçesi. Kod yazdığında veri hazırlığı adım adım görünür kalır ve bölge eşlemesi gibi bir dönüşüm bir tablo birleştirme (join) olarak yazılır — eşleşmeyen il olduğunda uyarı alırsın. Excel'de aynı işlem iki sütunun yan yana durmasından ibarettir ve hiza bozulduğunda kimse haber vermez.

Sınırlar

  • Bölge düzeltmesi dosyaya işlenmedi. Yukarıdaki düzeltilmiş rakamları ayrı bir kontrolle hesapladım; repodaki pano hâlâ özgün hâliyle duruyor.
  • Gayrimenkul verisi 2012'de bitiyor. Bulgular dönemin kendisi için geçerli; bugünkü piyasaya genellenemez.
  • Portföy modeli 21 işlem gününe dayanıyor. Bir aylık pencere, ortalama getiri tahmini için çok kısa; sonuçlar örneklem dönemine aşırı duyarlı.
  • İşlem maliyeti ve likidite yok. Model yalnızca getiri ve sapmayı dikkate alıyor; komisyon, vergi ve alım-satım farkı modele girmiyor.
  • Yatırım tavsiyesi değildir. Bu çalışma bir yöntem uygulamasıdır; hisse seçimi veya ağırlıklandırma önerisi içermez.

Sonuç

İki dosya, Excel'in iki farklı yüzünü gösteriyor: biri veriyi özetleyip görünür kılan bir raporlama aracı, diğeri küçük ölçekli bir optimizasyon motoru. İkisi de kendi işini yapıyor.

Asıl çıkarım ise araçla ilgili değil. Her iki dosyada da sayılar hesaplandı, grafikler çizildi ve hiçbir şey hata vermedi — ama birinde bölgelerin yarısı yanlış, diğerinde iki hisse yüz kat şişmişti. Bir analizin çalışması, doğru olduğu anlamına gelmiyor. Çıktıyı sorgulamak, onu üretmek kadar işin parçası.

Two counterexamples for anyone who thinks Excel is just “where tables live”: a dashboard that explores five years of property sales across 81 provinces with PivotTables and slicers, and a model that finds an optimal portfolio from nine BIST stocks with Solver. I reopened both, verified the numbers — and found one error that needed fixing in each.

Property data81 provinces2008–2012, three sale types
Total housing sales3.0 million828,878 of them mortgaged
Portfolio model9 stocks21 trading days, Solver

1. The property sales dashboard

The first file holds property sales across Turkey's 81 provinces between 2008 and 2012. For each province and year there are three breakdowns: total housing sales, the mortgaged portion, and non-mortgaged (other) sales.

The dashboard side is built with PivotTables: the distribution of sales across regions, the sale-type breakdown per region, and a chart driven by slicers for a selected province and year. Slicers are the most practical way to add interactivity without writing a formula — the user picks a province and a year, and every chart updates together.

YearHousing salesMortgagedMortgaged share
2008427,105—no data
2009555,18422,7264.1%
2010607,098246,74140.6%
2011708,275289,27540.8%
2012701,621270,13638.5%

Across the five years there are 2,999,283 housing sales, of which 828,878 were mortgaged. The most striking jump in the table is from 2009 to 2010: the mortgaged share climbs from 4.1% to 40.6% and stays at that level for the next two years.

Careful — this is not a “boom”: mortgaged sales in the 2008 column are not zero, they are blank. The source data has no mortgage breakdown for 2008; the cells hold a dash. The 4.1% in 2009 is probably a partial record too. So saying “there were no mortgaged sales in 2008” would be wrong; the correct statement is that mortgaged sales began to be reported separately during 2009–2010.

Concentration across provinces

ProvinceTotal housingShare of countryMortgaged share
İstanbul734,09824.5%34.1%
Ankara521,30517.4%26.5%
İzmir192,4626.4%33.1%
Antalya156,8485.2%23.7%
Bursa93,9053.1%31.5%
Kayseri77,1242.6%23.0%

İstanbul and Ankara alone account for 41.9% of housing sales nationwide. The mortgaged share is higher in the big cities too: İstanbul at 34.1% and İzmir at 33.1% sit above the 27.6% average, while Antalya and Kayseri fall below it.

2. The error in the dashboard: region assignments are off

The dashboard's main chart shows sales by region, and it put the Mediterranean region far out in front with 1,013,779 housing sales. That number did not look right — there is no province the size of İstanbul in the Mediterranean region.

I compared the region column in the data against TurkStat's NUTS Level-1 classification. 18 of the 81 provinces are assigned to the wrong region.

ProvinceRegion in the fileCorrect region
İstanbulMediterraneanİstanbul
İzmirWest MarmaraAegean
KocaeliSoutheast AnatoliaEast Marmara
KonyaEast MarmaraWest Anatolia
MersinSoutheast AnatoliaMediterranean
KayseriWest Black SeaCentral Anatolia
ManisaCentral East AnatoliaAegean
MalatyaAegeanCentral East Anatolia

The table shows eight of the misassigned provinces; 18 are affected in total. Every one of them falls alphabetically between İstanbul and Mersin. That points straight at the usual cause: one column was sorted on its own, or the region list lost its alignment with the province list. A textbook case of why Excel's “expand the selection?” warning deserves attention.

The impact is not small. Because İstanbul's 734,098 sales were booked to the Mediterranean region, the regional ranking changes completely:

RegionIn the fileCorrectedChange
İstanbul—734,098new region
West Anatolia538,846603,919+12%
Mediterranean1,013,779371,367−63%
Aegean144,676318,315+120%
East Marmara299,831259,708−13%
Southeast Anatolia281,146179,155−36%
Central Anatolia81,002160,947+99%
West Black Sea203,816130,872−36%
West Marmara268,43168,773−74%

After the correction the lead moves from the Mediterranean to İstanbul, the Aegean more than doubles, and West Marmara drops to a quarter of its reported figure. The total is unchanged (2,999,283) — it simply lands in the right regions.

A second detail: the TOTAL column in the data sums every yearly breakdown, so it counts each sale four times (for Adana it reads 281,780 instead of 70,445). One of the regional summaries is built on that column. The correct summary should come from the TOTAL HOUSING / TOTAL MORTGAGED / TOTAL OTHER columns.

3. Portfolio optimization with Solver

The second file is a completely different job: optimal portfolio selection with the Konno-Yamazaki model. The classical Markowitz approach measures risk with variance and produces a quadratic problem; Konno-Yamazaki measures risk with mean absolute deviation instead. The practical consequence is that the problem becomes linear and can be solved with Excel's Solver add-in.

Data

9 BIST stocks

GARAN, HALKB, ARCLK, KCHOL, TUPRS, THYAO, TOASO, MGROS, TTKOM — daily returns from 31.12.2020 to 29.01.2021.

Objective

Minimize absolute deviation

The total deviation of the portfolio's daily return from its mean is minimized.

Constraints

Weights sum to 100

No negative weights (no short selling) and a floor on the target return.

Tool

Excel Solver

Because the problem is linear it can be solved with Simplex LP; no extra software needed.

The model's result:

StockMean daily returnPortfolio weight
ARCLK0.53299.49%
GARAN−103.2650.51%
MGROS0.2930
TOASO0.2830
KCHOL−0.1240
THYAO−0.2640
TTKOM−0.3420
TUPRS−0.3450
HALKB−33.0240

The objective value is Z = 509.52. But two rows in that table jump out immediately.

4. Two problems in the portfolio model

A decimal error in the GARAN and HALKB series

GARAN's mean daily return reads −103.27 and HALKB's −33.02, while the other seven stocks sit between −0.35 and +0.53. Looking at the raw data makes the reason obvious: the GARAN column holds values like −85, −431 and −225. A 431% daily fall is impossible — these values are a hundred times too large, meaning the decimal separator was lost (−431 instead of −4.31).

The likely cause: when the data was copied from tr.investing.com, comma decimals did not match Excel's regional settings and the separator was dropped for two stocks. This is one of the most common errors when importing external data, and it happens silently: the cells look numeric, the formulas run, no warning appears.

The target return constraint forces a single solution

The target return constraint in the model is set equal to the highest achievable single-stock return (0.532 ≥ 0.532). With a constraint like that, there is only one thing the optimization can do: put almost all the money into that stock. And indeed the result is 99.49% ARCLK.

That is a consequence of the setup, not of the model. The point of portfolio optimization is to lower risk through diversification; once the target return is pinned to the maximum, there is no room left to diversify. For a meaningful result the target should be lowered and the efficient frontier traced across different targets: computing the minimum risk for each target return and plotting the curve.

What I would do differently: (1) recompute the return series from raw prices and check the decimal separator; (2) vary the target return across several levels and trace the efficient frontier; (3) widen the window to at least a year, since 21 trading days is far too short. All three can be done without changing the model — only the setup.

5. What these two studies say about Excel

Strength

PivotTables

Summarizing 81 provinces × 5 years × 3 breakdowns without writing a single formula, and making it interactive with slicers, takes minutes.

Strength

Solver

A linear optimization problem can be set up with no extra software, and the result lives in the same file.

Weakness

Silent errors

Neither the wrong region assignment nor the lost decimal separator produced any warning. The file opens, the charts render, the numbers are wrong.

Weakness

Traceability

The data preparation steps are not recorded inside the file; where a column came from cannot be reconstructed later.

Those two weaknesses are the real argument for doing the same analysis in R or Python. When you write code, the data preparation stays visible step by step, and a mapping like province-to-region becomes a join — one that warns you when a province fails to match. In Excel the same operation is just two columns sitting next to each other, and nothing tells you when the alignment breaks.

Limitations

  • The region fix was not written back into the file. The corrected figures above come from a separate check; the dashboard in the repository is still in its original state.
  • The property data ends in 2012. The findings hold for that period and do not generalize to today's market.
  • The portfolio model rests on 21 trading days. A one-month window is far too short for estimating mean returns; the results are highly sensitive to the sample period.
  • No transaction costs or liquidity. The model considers only returns and deviation; commissions, taxes and spreads are not included.
  • This is not investment advice. The study is an application of a method; it contains no stock selection or weighting recommendation.

Conclusion

The two files show two different faces of Excel: one a reporting tool that summarizes data and makes it visible, the other a small-scale optimization engine. Both do their job.

The real takeaway is not about the tool. In both files the numbers were computed, the charts were drawn and nothing raised an error — yet in one, half the regions were wrong, and in the other two stocks were inflated a hundredfold. An analysis running is not the same as an analysis being right. Questioning the output is as much a part of the job as producing it.